Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.python > #80553 > unrolled thread

I love assert

Back to article view | Back to comp.lang.python

Contents

  I love assert Peter Cacioppi <peter.cacioppi@gmail.com> - 2014-11-11 11:40 -0800
    Re: I love assert Ben Finney <ben+python@benfinney.id.au> - 2014-11-12 07:03 +1100
      Re: I love assert Grant Edwards <invalid@invalid.invalid> - 2014-11-11 21:43 +0000
    Re: I love assert Ethan Furman <ethan@stoneleaf.us> - 2014-11-11 12:08 -0800
    Re: I love assert Rob Gaddi <rgaddi@technologyhighland.invalid> - 2014-11-11 12:20 -0800
    Re: I love assert Mark Lawrence <breamoreboy@yahoo.co.uk> - 2014-11-11 20:34 +0000
    Re: I love assert TP <wingusr@gmail.com> - 2014-11-11 12:57 -0800
    Re: I love assert Terry Reedy <tjreedy@udel.edu> - 2014-11-11 17:34 -0500
    Re: I love assert Ben Finney <ben+python@benfinney.id.au> - 2014-11-12 09:52 +1100
    Re: I love assert Tim Chase <python.list@tim.thechases.com> - 2014-11-11 17:03 -0600
    Re: I love assert Peter Cacioppi <peter.cacioppi@gmail.com> - 2014-11-11 15:02 -0800
    Re: I love assert Ethan Furman <ethan@stoneleaf.us> - 2014-11-11 15:38 -0800
    Re: I love assert Dan Stromberg <drsalists@gmail.com> - 2014-11-11 17:56 -0800
    Re: I love assert Chris Angelico <rosuav@gmail.com> - 2014-11-12 13:21 +1100
    Re: I love assert Ben Finney <ben+python@benfinney.id.au> - 2014-11-12 13:35 +1100
      Re: I love assert Grant Edwards <invalid@invalid.invalid> - 2014-11-12 14:10 +0000
    Re: I love assert Chris Angelico <rosuav@gmail.com> - 2014-11-12 13:44 +1100
      Re: I love assert wxjmfauth@gmail.com - 2014-11-11 23:14 -0800
    Re: I love assert Terry Reedy <tjreedy@udel.edu> - 2014-11-12 03:29 -0500
    Re: I love assert Anton <anton.schattenfeld@gmail.com> - 2014-11-12 12:53 -0800
      Re: I love assert Marko Rauhamaa <marko@pacujo.net> - 2014-11-12 23:41 +0200
        Re: I love assert Ethan Furman <ethan@stoneleaf.us> - 2014-11-12 13:52 -0800
          Re: I love assert Marko Rauhamaa <marko@pacujo.net> - 2014-11-12 23:56 +0200
            Re: I love assert Ian Kelly <ian.g.kelly@gmail.com> - 2014-11-12 15:04 -0700
              Re: I love assert Anton <anschatten@gmail.com> - 2014-11-12 14:13 -0800
                Re: I love assert Ian Kelly <ian.g.kelly@gmail.com> - 2014-11-12 15:41 -0700
                  Re: I love assert Anton <anschatten@gmail.com> - 2014-11-12 14:48 -0800
                    Re: I love assert Marko Rauhamaa <marko@pacujo.net> - 2014-11-13 01:01 +0200
                      Re: I love assert Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2014-11-15 10:40 +1100
                        Re: I love assert Marko Rauhamaa <marko@pacujo.net> - 2014-11-15 02:12 +0200
                          Re: I love assert Chris Angelico <rosuav@gmail.com> - 2014-11-15 12:04 +1100
                            Re: I love assert Marko Rauhamaa <marko@pacujo.net> - 2014-11-15 03:30 +0200
                              Re: I love assert Chris Angelico <rosuav@gmail.com> - 2014-11-15 12:48 +1100
                              Re: I love assert Tim Chase <python.list@tim.thechases.com> - 2014-11-14 20:14 -0600
                              Re: I love assert Chris Angelico <rosuav@gmail.com> - 2014-11-15 13:16 +1100
                              Re: I love assert albert@spenarnc.xs4all.nl (Albert van der Horst) - 2014-11-29 17:35 +0000
                    Re: I love assert Ian Kelly <ian.g.kelly@gmail.com> - 2014-11-12 16:02 -0700
                      Re: I love assert Anton <anschatten@gmail.com> - 2014-11-12 15:43 -0800
                    Re: I love assert Chris Angelico <rosuav@gmail.com> - 2014-11-13 10:10 +1100
                      Re: I love assert Marko Rauhamaa <marko@pacujo.net> - 2014-11-13 01:23 +0200
                        Re: I love assert Chris Angelico <rosuav@gmail.com> - 2014-11-13 10:27 +1100
                          Re: I love assert Marko Rauhamaa <marko@pacujo.net> - 2014-11-13 01:31 +0200
                Re: I love assert Ethan Furman <ethan@stoneleaf.us> - 2014-11-12 14:47 -0800
                  Re: I love assert Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2014-11-14 22:37 +1100
                    Re: I love assert Ian Kelly <ian.g.kelly@gmail.com> - 2014-11-14 09:40 -0700
            Re: I love assert Ian Kelly <ian.g.kelly@gmail.com> - 2014-11-12 15:07 -0700
              Re: I love assert Marko Rauhamaa <marko@pacujo.net> - 2014-11-13 00:47 +0200
                Re: I love assert Ethan Furman <ethan@stoneleaf.us> - 2014-11-12 14:56 -0800
                Re: I love assert Chris Angelico <rosuav@gmail.com> - 2014-11-13 09:58 +1100
                Re: I love assert Ian Kelly <ian.g.kelly@gmail.com> - 2014-11-12 16:05 -0700
                  Re: I love assert Marko Rauhamaa <marko@pacujo.net> - 2014-11-13 01:12 +0200
                Re: I love assert Lie Ryan <lie.1296@gmail.com> - 2014-11-14 01:09 +1100
          Re: I love assert Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2014-11-14 22:33 +1100
            Re: I love assert Ethan Furman <ethan@stoneleaf.us> - 2014-11-14 10:18 -0800
              Re: I love assert Marko Rauhamaa <marko@pacujo.net> - 2014-11-14 21:12 +0200
                Re: I love assert Ethan Furman <ethan@stoneleaf.us> - 2014-11-14 12:41 -0800
                  Re: I love assert Marko Rauhamaa <marko@pacujo.net> - 2014-11-14 22:50 +0200
              Re: I love assert Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2014-11-15 13:58 +1100
                Re: I love assert Ethan Furman <ethan@stoneleaf.us> - 2014-11-14 20:09 -0800
                  Re: I love assert Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2014-11-17 13:09 +1100
                    Re: I love assert Ethan Furman <ethan@stoneleaf.us> - 2014-11-16 19:25 -0800
        Re: I love assert Anton <anschatten@gmail.com> - 2014-11-12 14:00 -0800
          Re: I love assert Anton <anschatten@gmail.com> - 2014-11-12 14:04 -0800
            Re: I love assert Marko Rauhamaa <marko@pacujo.net> - 2014-11-13 00:34 +0200
      Re: I love assert Chris Angelico <rosuav@gmail.com> - 2014-11-13 09:43 +1100
    Re: I love assert Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2014-11-14 22:15 +1100
    Re: I love assert Richard Riehle <rriehle@itu.edu> - 2014-11-14 14:09 -0800
      Decorators (was: Re: I love assert) Marko Rauhamaa <marko@pacujo.net> - 2014-11-15 00:18 +0200
        Re: Decorators Mark Lawrence <breamoreboy@yahoo.co.uk> - 2014-11-14 22:37 +0000
          Re: Decorators Marko Rauhamaa <marko@pacujo.net> - 2014-11-15 00:47 +0200
        Re: Decorators (was: Re: I love assert) Richard Riehle <rriehle@itu.edu> - 2014-11-14 18:19 -0800
          Re: Decorators (was: Re: I love assert) Mayank Tripathi <oquanox@gmail.com> - 2014-11-15 02:36 +0000
          Re: Decorators (was: Re: I love assert) Tim Chase <python.list@tim.thechases.com> - 2014-11-14 20:30 -0600
            Re: Decorators Marko Rauhamaa <marko@pacujo.net> - 2014-11-15 09:00 +0200
              Re: Decorators Grant Edwards <invalid@invalid.invalid> - 2014-11-15 15:32 +0000
          Re: Decorators (was: Re: I love assert) Richard Riehle <rriehle@itu.edu> - 2014-11-14 23:42 -0800
          Re: Decorators Mark Lawrence <breamoreboy@yahoo.co.uk> - 2014-11-15 13:12 +0000
            Re: Decorators Marko Rauhamaa <marko@pacujo.net> - 2014-11-15 15:24 +0200
              Re: Decorators Terry Reedy <tjreedy@udel.edu> - 2014-11-15 15:28 -0500
          Re: Decorators (was: Re: I love assert) Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2014-11-16 02:39 +1100
    Re: I love assert TP <wingusr@gmail.com> - 2014-11-27 01:22 -0800
      Re: I love assert alister <alister.nospam.ware@ntlworld.com> - 2014-11-27 09:59 +0000
        Re: I love assert Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2014-11-29 12:30 +1100
          Re: I love assert MRAB <python@mrabarnett.plus.com> - 2014-11-29 02:56 +0000
            Re: I love assert Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2014-11-29 20:31 +1100
              Re: I love assert Chris Angelico <rosuav@gmail.com> - 2014-11-29 21:40 +1100
              Re: I love assert MRAB <python@mrabarnett.plus.com> - 2014-11-29 19:49 +0000
          Re: I love assert Chris Angelico <rosuav@gmail.com> - 2014-11-29 14:02 +1100
          Re: I love assert Ethan Furman <ethan@stoneleaf.us> - 2014-11-29 14:33 -0800
            Re: I love assert Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2014-11-30 19:18 +1100
              Re: I love assert Ethan Furman <ethan@stoneleaf.us> - 2014-11-30 11:34 -0800

Page 1 of 5  [1] 2 3 4 5  Next page →

#80553 — I love assert

I get the impression that most Pythonistas aren't as habituated with assert statements as I am. Is that just a misimpression on my part? If not, is there a good reason to assert less with Python than other languages?

As far as I can tell, Python supports assert perfectly well. When run with the optimization flagging, the asserts are truly removed.

I think one needs to take care with some basic assert coding - it's not a substitute for unit tests, it doesn't absolve you of normal exception responsibilities, and, most of all, it should be used for passive inspection and not action. But given these guidelines, I still find it very useful as "active comments".

[toc] | [next] | [standalone]

#80555

Peter Cacioppi <peter.cacioppi@gmail.com> writes:

> I get the impression that most Pythonistas aren't as habituated with
> assert statements as I am. Is that just a misimpression on my part? If
> not, is there a good reason to assert less with Python than other
> languages?

I don't know about comparisons like “use less with Python than other
languages”. But I can explain why I don't use ‘assert’ much.

> As far as I can tell, Python supports assert perfectly well. When run
> with the optimization flagging, the asserts are truly removed.

Exactly. I prefer the code I write to have as few surprises as possible.
A reader familiar with Python should be able to read it and know what it
does; ideally, even if that reader doesn't recall every detail of how
Python operates.

An ‘assert’ statement in the code will sometimes be active, and
sometimes be a no-op, for *exactly* the same code under different
circumstances. That's a trap for the reader, and I'd rather not set it.

> I think one needs to take care with some basic assert coding - it's
> not a substitute for unit tests, it doesn't absolve you of normal
> exception responsibilities, and, most of all, it should be used for
> passive inspection and not action. But given these guidelines, I still
> find it very useful as "active comments".

It's fine for debugging code while developing. But, in my opinion, it
should never stay there, and should be removed before committing to VCS.

-- 
 \         “True greatness is measured by how much freedom you give to |
  `\      others, not by how much you can coerce others to do what you |
_o__)                                               want.” —Larry Wall |
Ben Finney

[toc] | [prev] | [next] | [standalone]

#80568

On 2014-11-11, Ben Finney <ben+python@benfinney.id.au> wrote:

> An ‘assert’ statement in the code will sometimes be active, and
> sometimes be a no-op, for *exactly* the same code under different
> circumstances.

Yep, it's the same in C, C++, Java, PHP, and other languages.  I think
most people know that asserts can be disabled (either at run-time or
compile time), and often are for performance reasons.

> That's a trap for the reader, and I'd rather not set it.

Personally, I find that too many asserts often makes code hard to read
just because of the visual clutter and the veritical "spread" it
induces.

-- 
Grant Edwards               grant.b.edwards        Yow! I hope I bought the
                                  at               right relish ... zzzzzzzzz
                              gmail.com            ...

[toc] | [prev] | [next] | [standalone]

#80558

On 11/11/2014 11:40 AM, Peter Cacioppi wrote:
>
> I get the impression that most Pythonistas aren't as habituated with assert statements
>  as I am. Is that just a misimpression on my part? If not, is there a good reason to
>  assert less with Python than other languages?
>
> As far as I can tell, Python supports assert perfectly well. When run with the optimization
>  flagging, the asserts are truly removed.
>
> I think one needs to take care with some basic assert coding - it's not a substitute for
>  unit tests, it doesn't absolve you of normal exception responsibilities, and, most of all,
>  it should be used for passive inspection and not action. But given these guidelines, I
>  still find it very useful as "active comments".

asserts are a specialized tool, easily abused.  Sounds like you are using them exactly as intended.

The key question to ask (if one is curious whether one is using assert correctly) is:  if all the asserts are removed, 
and my programs gets bad data, will it keep going as if it had gotten good data?  Or, will it fail at the point it 
should have failed, or will it fail somewhere else?

--
~Ethan~

[toc] | [prev] | [next] | [standalone]

#80559

On Tue, 11 Nov 2014 11:40:38 -0800 (PST)
Peter Cacioppi <peter.cacioppi@gmail.com> wrote:

> I get the impression that most Pythonistas aren't as habituated with assert statements as I am. Is that just a misimpression on my part? If not, is there a good reason to assert less with Python than other languages?
> 
> As far as I can tell, Python supports assert perfectly well. When run with the optimization flagging, the asserts are truly removed.
> 
> I think one needs to take care with some basic assert coding - it's not a substitute for unit tests, it doesn't absolve you of normal exception responsibilities, and, most of all, it should be used for passive inspection and not action. But given these guidelines, I still find it very useful as "active comments".
> 

I tend to be a big fan, but it is easy to forget about the one big rake
assert leaves in your lawn.  You CAN NOT use an assert with any
function that has a side effect or you break everything.

assert test_and_set(var)

That line there is pretty obvious about what's going on, but with the
ability to turn class data members transparently into properties, using
asserts safely actually requires a shocking amount of self-discipline.

assert obj.read_accesses < 10

-- 
Rob Gaddi, Highland Technology -- www.highlandtechnology.com
Email address domain is currently out of order.  See above to fix.

[toc] | [prev] | [next] | [standalone]

#80560

On 11/11/2014 19:40, Peter Cacioppi wrote:
> I get the impression that most Pythonistas aren't as habituated with assert statements as I am. Is that just a misimpression on my part? If not, is there a good reason to assert less with Python than other languages?
>
> As far as I can tell, Python supports assert perfectly well. When run with the optimization flagging, the asserts are truly removed.
>
> I think one needs to take care with some basic assert coding - it's not a substitute for unit tests, it doesn't absolve you of normal exception responsibilities, and, most of all, it should be used for passive inspection and not action. But given these guidelines, I still find it very useful as "active comments".
>

Please check this out 
https://mail.python.org/pipermail/python-list/2013-November/660401.html 
as it was released to critical acclaim :)

-- 
My fellow Pythonistas, ask not what our language can do for you, ask
what you can do for our language.

Mark Lawrence

[toc] | [prev] | [next] | [standalone]

#80562

[Multipart message — attachments visible in raw view] — view raw

On Tue, Nov 11, 2014 at 11:40 AM, Peter Cacioppi <peter.cacioppi@gmail.com>
wrote:

> I think one needs to take care with some basic assert coding - it's not a
> substitute for unit tests, it doesn't absolve you of normal exception
> responsibilities, and, most of all, it should be used for passive
> inspection and not action. But given these guidelines, I still find it very
> useful as "active comments".


I first came across asserts when using Wing IDE. See "Helping Wing Analyze
Code" [1] explains why using assert and isinstance will let Wing IDE
autocomplete things it otherwise couldn't.

PyCharm uses docstrings to accomplish the same task [2] but can also use
asserts/isinstance [3].

[1] https://wingware.com/doc/edit/helping-wing-analyze-code

[2] https://www.jetbrains.com/pycharm/webhelp/type-hinting-in-pycharm.html
<https://www.jetbrains.com/pycharm/webhelp/type-hinting-in-pycharm.html#d232466e456>

[3]
http://stackoverflow.com/questions/9040387/is-there-a-way-to-explicitly-tell-pycharm-what-class-an-attribute-is-an-instance

[toc] | [prev] | [next] | [standalone]

#80572

On 11/11/2014 2:40 PM, Peter Cacioppi wrote:
> I get the impression that most Pythonistas aren't as habituated with
> assert statements as I am. Is that just a misimpression on my part?
> If not, is there a good reason to assert less with Python than other
> languages?

We love 'assert' so much that we have 20-30 'assertXYZ' variations in 
unittest.  The statement 'assert expression' is almost equivalent to

if not expression: raise AssertionError('expression')

We have perhaps 100 mostly more specialized exceptions builtin and in 
the stdlib.  There is nearly always a better, more specific exception 
and error message.

> As far as I can tell, Python supports assert perfectly well. When run
> with the optimization flagging, the asserts are truly removed.

Separating tests from main code removes test asserts from the main code. 
  Removal by -0 relegates bare assert to specialized usage.

> I think one needs to take care with some basic assert coding - it's
> not a substitute for unit tests, it doesn't absolve you of normal
> exception responsibilities, and, most of all, it should be used for
> passive inspection and not action. But given these guidelines, I
> still find it very useful as "active comments".

How much usage depends considerably on the programmer.

-- 
Terry Jan Reedy

[toc] | [prev] | [next] | [standalone]

#80573

Terry Reedy <tjreedy@udel.edu> writes:

> We love 'assert' so much that we have 20-30 'assertXYZ' variations in
> unittest.

A function will not be disabled by a run-time option to the Python
interpreter.

> The statement 'assert expression' is almost equivalent to
>
> if not expression: raise AssertionError('expression')

With the important difference that this will be active no matter what
options Python's interpreter is run with. That makes it quite a
different proposition from using ‘assert’ statements.

-- 
 \     “You don't need a book of any description to help you have some |
  `\    kind of moral awareness.” —Dr. Francesca Stavrakoloulou, bible |
_o__)                                              scholar, 2011-05-08 |
Ben Finney

[toc] | [prev] | [next] | [standalone]

#80574

On 2014-11-11 11:40, Peter Cacioppi wrote:
> I get the impression that most Pythonistas aren't as habituated
> with assert statements as I am. Is that just a misimpression on my
> part?

I tend to use it to catch my bone-headedness rather than actual
tests.  I'm particularly fond of one that catches me typing
"obj.exceptions" rather than "obj.exemptions" (both are common and
occasionally interchangeable terms in $DAYJOB) something along the
lines of

  assert hasattr(obj, "exceptions"), "idiot programmer"

-tkc

[toc] | [prev] | [next] | [standalone]

#80575

[Multipart message — attachments visible in raw view] — view raw

On Tue, Nov 11, 2014 at 12:57 PM, TP <wingusr@gmail.com> wrote:

> On Tue, Nov 11, 2014 at 11:40 AM, Peter Cacioppi <peter.cacioppi@gmail.com
> > wrote:
>
>> I think one needs to take care with some basic assert coding - it's not a
>> substitute for unit tests, it doesn't absolve you of normal exception
>> responsibilities, and, most of all, it should be used for passive
>> inspection and not action. But given these guidelines, I still find it very
>> useful as "active comments".
>
>
> I first came across asserts when using Wing IDE. See "Helping Wing Analyze
> Code" [1] explains why using assert and isinstance will let Wing IDE
> autocomplete things it otherwise couldn't.
>
> PyCharm uses docstrings to accomplish the same task [2] but can also use
> asserts/isinstance [3].
>
> [1] https://wingware.com/doc/edit/helping-wing-analyze-code
>
> [2] https://www.jetbrains.com/pycharm/webhelp/type-hinting-in-pycharm.html
> <https://www.jetbrains.com/pycharm/webhelp/type-hinting-in-pycharm.html#d232466e456>
>
> [3]
> http://stackoverflow.com/questions/9040387/is-there-a-way-to-explicitly-tell-pycharm-what-class-an-attribute-is-an-instance
>
>
I use PyCharm. Thanks for [2], it's a keeper

[toc] | [prev] | [next] | [standalone]

#80576

On 11/11/2014 03:02 PM, Peter Cacioppi wrote:
> On Tue, Nov 11, 2014 at 12:57 PM, TP wrote:
>>
>> PyCharm uses docstrings to accomplish the same task [2] but can also use asserts/isinstance [3].
>>
>> [2] https://www.jetbrains.com/pycharm/webhelp/type-hinting-in-pycharm.html
>> <https://www.jetbrains.com/pycharm/webhelp/type-hinting-in-pycharm.html#d232466e456>
>
> I use PyCharm. Thanks for [2], it's a keeper

Please, please don't use isinstance when you don't need to.  It just makes your code unusable to anybody who wants/needs 
to use a different-yet-compatible type than the one you checked for.

--
~Ethan~

[toc] | [prev] | [next] | [standalone]

#80585

On Tue, Nov 11, 2014 at 11:40 AM, Peter Cacioppi
<peter.cacioppi@gmail.com> wrote:
> I get the impression that most Pythonistas aren't as habituated with assert statements as I am. Is that just a misimpression on my part? If not, is there a good reason to assert less with Python than other languages?
>
> As far as I can tell, Python supports assert perfectly well. When run with the optimization flagging, the asserts are truly removed.
>
> I think one needs to take care with some basic assert coding - it's not a substitute for unit tests, it doesn't absolve you of normal exception responsibilities, and, most of all, it should be used for passive inspection and not action. But given these guidelines, I still find it very useful as "active comments".

assert is terrific (stops bugs in their tracks), though many things
should be done with more targeted exceptions.

I guess you could do a survey.

[toc] | [prev] | [next] | [standalone]

#80586

On Wed, Nov 12, 2014 at 7:03 AM, Ben Finney <ben+python@benfinney.id.au> wrote:
> An ‘assert’ statement in the code will sometimes be active, and
> sometimes be a no-op, for *exactly* the same code under different
> circumstances. That's a trap for the reader, and I'd rather not set it.

This is no worse than other forms of preprocessor magic. I've seen
this kind of thing in plenty of C projects:

#ifdef DEBUG_MODE
#define DEBUG print
#else
#define DEBUG(...)
#endif

... further down ...
DEBUG("We're here: %d:%d", foo, bar);

If you're not in debug mode, this won't be evaluated. You can have
"active code" inside its args if you want to, but only if it's
exclusively part of the debugging output:

DEBUG("We've hit this line %d times", ++hitcount);

Again, not materially different from assert, and plenty of projects
have this. Maybe people just need to understand "assert == DEBUG" and
all's clear?

ChrisA

[toc] | [prev] | [next] | [standalone]

#80588

Chris Angelico <rosuav@gmail.com> writes:

> On Wed, Nov 12, 2014 at 7:03 AM, Ben Finney <ben+python@benfinney.id.au> wrote:
> > An ‘assert’ statement in the code will sometimes be active, and
> > sometimes be a no-op, for *exactly* the same code under different
> > circumstances. That's a trap for the reader, and I'd rather not set
> > it.
>
> This is no worse than other forms of preprocessor magic.

That other languages do it doesn't argue in favour of it. It argues,
rather, that we should be glad not to have it in our Python code.

> Again, not materially different from assert, and plenty of projects
> have this. Maybe people just need to understand "assert == DEBUG" and
> all's clear?

The more things people need to keep in mind when reading my code that
isn't stated explicitly in the code, the worse I consider the code to
be.

Python is a small, clear, expressive language. It has the valuable
property that one does not need to keep in mind a lot of reminders of
unexpected behaviour; good Python code behaves as it explicitly says it
will, with very few implied surprises.

To preserve this valuable but fragile property, I recommend treating
‘assert’ as a clever but obfuscatory trick, opposed to that property of
Python. So an ‘assert’ statement should, IMO, not remain in the code
past a debugging session.

-- 
 \          “The entertainment industry calls DRM "security" software, |
  `\         because it makes them secure from their customers.” —Cory |
_o__)                                             Doctorow, 2014-02-05 |
Ben Finney

[toc] | [prev] | [next] | [standalone]

#80604

On 2014-11-12, Ben Finney <ben+python@benfinney.id.au> wrote:
> Chris Angelico <rosuav@gmail.com> writes:
>
>> On Wed, Nov 12, 2014 at 7:03 AM, Ben Finney <ben+python@benfinney.id.au> wrote:
>> > An ‘assert’ statement in the code will sometimes be active, and
>> > sometimes be a no-op, for *exactly* the same code under different
>> > circumstances. That's a trap for the reader, and I'd rather not set
>> > it.
>>
>> This is no worse than other forms of preprocessor magic.
>
> That other languages do it doesn't argue in favour of it. It argues,
> rather, that we should be glad not to have it in our Python code.

Technically it's not an argument for assert, but I think it is a
refutation of one of your arguments against assert. It refutes your
statement that the fact that asserts may not always be active is a
suprise to people and therefore acts as a "trap".

-- 
Grant Edwards               grant.b.edwards        Yow! Is it clean in other
                                  at               dimensions?
                              gmail.com            

[toc] | [prev] | [next] | [standalone]

#80589

On Wed, Nov 12, 2014 at 1:35 PM, Ben Finney <ben+python@benfinney.id.au> wrote:
> The more things people need to keep in mind when reading my code that
> isn't stated explicitly in the code, the worse I consider the code to
> be.

Then the ternary if/else operator should also be abolished.

track["APIC:"].data if "APIC:" in track else None

(With PEP 463, this would be:
track["APIC:"].data except KeyError: None
But this is from Python 2.7 code, so that was never going to happen anyway.)

When you read the if/else version, you need to remember that it's
evaluated middle-to-outside rather than outside-to-inside, and more
importantly, that the first expression won't be evaluated at all if
the key isn't present. So should we treat if/else as a "clever but
obfuscatory trick, opposed to that property of Python" too? Or should
people just get to know the language they're using? At least with
'assert', it's consistent across all Python programs; with my DEBUG
example, it's per-project, as it's custom crafted.

ChrisA

[toc] | [prev] | [next] | [standalone]

#80592

%%%%%%%%

Does "assert" work, if Python fails (ev. crashes) on
valid strings?   :-)

jmf

[toc] | [prev] | [next] | [standalone]

#80594

On 11/11/2014 5:52 PM, Ben Finney wrote:
> Terry Reedy <tjreedy@udel.edu> writes:
>
>> We love 'assert' so much that we have 20-30 'assertXYZ' variations in
>> unittest.
>
> A function will not be disabled by a run-time option to the Python
> interpreter.
>
>> The statement 'assert expression' is almost equivalent to
>>
>> if not expression: raise AssertionError('expression')
>
> With the important difference that this will be active no matter what
> options Python's interpreter is run with. That makes it quite a
> different proposition from using ‘assert’ statements.

Which importand difference I pointed out (and you snipped) as a reason 
to seldom use bare assert.

-- 
Terry Jan Reedy

[toc] | [prev] | [next] | [standalone]

#80625

On Tuesday, November 11, 2014 11:41:06 AM UTC-8, Peter Cacioppi wrote:
> I get the impression that most Pythonistas aren't as habituated with assert statements as I am. Is that just a misimpression on my part? If not, is there a good reason to assert less with Python than other languages?
> 
> As far as I can tell, Python supports assert perfectly well. When run with the optimization flagging, the asserts are truly removed.
> 
> I think one needs to take care with some basic assert coding - it's not a substitute for unit tests, it doesn't absolve you of normal exception responsibilities, and, most of all, it should be used for passive inspection and not action. But given these guidelines, I still find it very useful as "active comments".

I am not sure how and when you use assert, but something that stops me from using assert is that in many cases I would use them to 
1) Check type of an incoming argument/returned value
2) Check value of an incoming argument/returned value
But the issues I can see here is that assert throws AssertError, while there is a specialized error for each of the case: 1) TypeError 2) ValueError.
Moreover for the 1) case it makes it impossible to dynamically substitute an object with another object that implements the same interface.

[toc] | [prev] | [next] | [standalone]

Page 1 of 5  [1] 2 3 4 5  Next page →

Back to top | Article view | comp.lang.python

csiph-web