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 3 of 5 — ← Prev page 1 2 [3] 4 5  Next page →

#80661

On Thu, Nov 13, 2014 at 10:23 AM, Marko Rauhamaa <marko@pacujo.net> wrote:
> However, the programmer could have played this frustration out already
> in his head and written:
>
>      assert len(choices) > 0
>      count = next_size / len(choices)

assert choices
count = next_size / len(choices)

Or even just:

count = next_size / len(choices) # choices won't be empty

ChrisA

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

#80662

Chris Angelico <rosuav@gmail.com>:

> On Thu, Nov 13, 2014 at 10:23 AM, Marko Rauhamaa <marko@pacujo.net> wrote:
>> However, the programmer could have played this frustration out already
>> in his head and written:
>>
>>      assert len(choices) > 0
>>      count = next_size / len(choices)
>
> assert choices
> count = next_size / len(choices)
>
> Or even just:
>
> count = next_size / len(choices) # choices won't be empty

Precisely.


Marko

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

#80649

On 11/12/2014 02:41 PM, Ian Kelly wrote:
> On Wed, Nov 12, 2014 at 3:13 PM, Anton <anschatten@gmail.com> wrote:
>> On Wednesday, November 12, 2014 2:05:17 PM UTC-8, Ian wrote:
>>> You don't need to remove it. Just reorganize it to make sure it
>>> indicates actual exhaustion of possibilities. E.g. using the "assert
>>> False" pattern from your post:
>>>
>>> if status == OK:
>>>      ...
>>> elif status == ERROR:
>>>      ...
>>> elif status == WARNING:
>>>      ...
>>> else:
>>>      assert False
>>
>> If the code is run optimized and asserts are ignore CONFUSED statement would still not be handled and you will not know about it.
>> I would do something like:
>
> There's no way to make the CONFUSED status be handled without actually
> changing the code. The difference is that this version will not
> incorrectly treat CONFUSED as WARNING; it just won't do anything at
> all if the code is optimized.

So, a different wrong thing, but still a wrong thing.  ;)

--
~Ethan~

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

#80758

Ethan Furman wrote:

>> There's no way to make the CONFUSED status be handled without actually
>> changing the code. The difference is that this version will not
>> incorrectly treat CONFUSED as WARNING; it just won't do anything at
>> all if the code is optimized.
> 
> So, a different wrong thing, but still a wrong thing.  ;)


And potentially a *worse* wrong thing.


   "I find it amusing when novice programmers believe their main 
    job is preventing programs from crashing. ... More experienced
    programmers realize that correct code is great, code that 
    crashes could use improvement, but incorrect code that doesn’t 
    crash is a horrible nightmare."
    -- Chris Smith


Assertions can help by this, by causing wrong code to fail as soon as
possible (provided, of course, that you don't defeat the assertions by
running the code with assertions disabled).



-- 
Steven

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

#80775

On Fri, Nov 14, 2014 at 4:37 AM, Steven D'Aprano
<steve+comp.lang.python@pearwood.info> wrote:
> Ethan Furman wrote:
>
>>> There's no way to make the CONFUSED status be handled without actually
>>> changing the code. The difference is that this version will not
>>> incorrectly treat CONFUSED as WARNING; it just won't do anything at
>>> all if the code is optimized.
>>
>> So, a different wrong thing, but still a wrong thing.  ;)
>
> And potentially a *worse* wrong thing.

Potentially it's worse, but more likely doing the wrong thing will be
worse than doing nothing.

>    "I find it amusing when novice programmers believe their main
>     job is preventing programs from crashing. ... More experienced
>     programmers realize that correct code is great, code that
>     crashes could use improvement, but incorrect code that doesn’t
>     crash is a horrible nightmare."
>     -- Chris Smith
>
> Assertions can help by this, by causing wrong code to fail as soon as
> possible (provided, of course, that you don't defeat the assertions by
> running the code with assertions disabled).

I fail to see the relevance of this quote. The code I posted that
you're responding to does use an assertion. The case where it does "a
different wrong thing" is precisely the case where assertions are
disabled.

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

#80641

On Wed, Nov 12, 2014 at 3:04 PM, Ian Kelly <ian.g.kelly@gmail.com> wrote:
> On Wed, Nov 12, 2014 at 2:56 PM, Marko Rauhamaa <marko@pacujo.net> wrote:
>> How would it be better if you removed the assert then?
>
> You don't need to remove it. Just reorganize it to make sure it
> indicates actual exhaustion of possibilities. E.g. using the "assert
> False" pattern from your post:
>
> if status == OK:
>     ...
> elif status == ERROR:
>     ...
> elif status == WARNING:
>     ...
> else:
>     assert False

Although to be honest I'd rather use something like "raise
RuntimeError('Unreachable code reached')" than "assert False" here. If
the expectation is that the code will never be executed, then there's
no reason to ever optimize it out.

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

#80648

Ian Kelly <ian.g.kelly@gmail.com>:

> Although to be honest I'd rather use something like "raise
> RuntimeError('Unreachable code reached')" than "assert False" here. If
> the expectation is that the code will never be executed, then there's
> no reason to ever optimize it out.

Asserts have nothing to do with them being optimized out. Asserts are
communication.

Apart from idiomatic style, there is no difference between

    # never reached

    assert False

    raise RuntimeError('Unreachable code reached')

    1 / 0

    print("Hello world")

since, after all, that line is never reached!

Out of these variants, I find

    assert False

to be the most tasteful. It is concise, to the point and provided by the
core language. If it didn't exist, I'd have to resort to one of the
other alternatives.


Marko

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

#80651

On 11/12/2014 02:47 PM, Marko Rauhamaa wrote:
> Ian Kelly <ian.g.kelly@gmail.com>:
>
>> Although to be honest I'd rather use something like "raise
>> RuntimeError('Unreachable code reached')" than "assert False" here. If
>> the expectation is that the code will never be executed, then there's
>> no reason to ever optimize it out.
>
> Asserts have nothing to do with them being optimized out. Asserts are
> communication.

Asserts are code that can stop your program.  That's a bit more than just communication.  And your example of how you 
use asserts shows a bad way to use them, which has been explained.  Apparently you refuse to learn from that, but 
hopefully somebody else will.

--
~Ethan~

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

#80652

On Thu, Nov 13, 2014 at 9:47 AM, Marko Rauhamaa <marko@pacujo.net> wrote:
> Apart from idiomatic style, there is no difference between
>
>     # never reached
>
>     assert False
>
>     raise RuntimeError('Unreachable code reached')
>
>     1 / 0
>
>     print("Hello world")
>
> since, after all, that line is never reached!

If it truly is never reached, there's no difference between any of the
above and "pass". (With the possible exception of 1/0, which might
plausibly be optimized to a constant, which would mean it'd throw an
error at compile time.) But what if, one day, it is reached? What
should happen? RuntimeError implies that there's an error that
couldn't be detected until run time. AssertionError might not get
raised. Printing "Hello world" to standard out will almost certainly
be misinterpreted. ZeroDivisionError makes almost no sense for
"shouldn't happen". Think about what your code ought to do *if it is
reached*, because if you really don't care about that case, you won't
have a line of code at all.

ChrisA

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

#80655

On Wed, Nov 12, 2014 at 3:47 PM, Marko Rauhamaa <marko@pacujo.net> wrote:
> Ian Kelly <ian.g.kelly@gmail.com>:
>
>> Although to be honest I'd rather use something like "raise
>> RuntimeError('Unreachable code reached')" than "assert False" here. If
>> the expectation is that the code will never be executed, then there's
>> no reason to ever optimize it out.
>
> Asserts have nothing to do with them being optimized out. Asserts are
> communication.
>
> Apart from idiomatic style, there is no difference between
>
>     # never reached
>
>     assert False
>
>     raise RuntimeError('Unreachable code reached')

If the purpose is communication, then the comment is most effective,
as it can easily convey anything you want. If the purpose is to detect
programming errors, then the RuntimeError is most effective, as it
will always raise an error in the event it is reached.

assert False is a strange hybrid of the two that is less effective at
both purposes.

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

#80657

Ian Kelly <ian.g.kelly@gmail.com>:

> On Wed, Nov 12, 2014 at 3:47 PM, Marko Rauhamaa <marko@pacujo.net> wrote:
>> Asserts have nothing to do with them being optimized out. Asserts are
>> communication.
>>
>> Apart from idiomatic style, there is no difference between
>>
>>     # never reached
>>
>>     assert False
>>
>>     raise RuntimeError('Unreachable code reached')
>
> If the purpose is communication, then the comment is most effective,
> as it can easily convey anything you want. If the purpose is to detect
> programming errors, then the RuntimeError is most effective, as it
> will always raise an error in the event it is reached.
>
> assert False is a strange hybrid of the two that is less effective at
> both purposes.

If assert weren't there, I would likely choose one of those two
alternatives. But assert is there so there's no reason to avoid it.


Marko

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

#80686

On 13/11/14 10:05, Ian Kelly wrote:
> On Wed, Nov 12, 2014 at 3:47 PM, Marko Rauhamaa <marko@pacujo.net> wrote:
>> Ian Kelly <ian.g.kelly@gmail.com>:
>>
>> Apart from idiomatic style, there is no difference between
>>
>>      # never reached
>>
>>      assert False
>>
>>      raise RuntimeError('Unreachable code reached')
>
> If the purpose is communication, then the comment is most effective,
> as it can easily convey anything you want. If the purpose is to detect
> programming errors, then the RuntimeError is most effective, as it
> will always raise an error in the event it is reached.
>
> assert False is a strange hybrid of the two that is less effective at
> both purposes.
>

You can do;

     assert False, "Some comments about why this assert is here"

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

#80757

Ethan Furman wrote:

> On 11/12/2014 01:41 PM, Marko Rauhamaa wrote:
>>
>> Or I might indicate the exhaustion of possibilities:
>>
>>       if status == OK:
>>           ...
>>       elif status == ERROR:
>>           ...
>>       else:
>>           assert status == WARNING
>>           ...
> 
> And here's a nice example of what one should NOT do.  Imagine that a new
> status, CONFUSED is added, the above code is not modified to handle it,
> and for whatever reason the program is being run optimized -- the assert
> is not there, and CONFUSED is treated the same as WARNING.

I agree with Marko in this case. Marko's example of defensive programming is
very similar to the one I gave in my essay here:

http://import-that.dreamwidth.org/676.html

You're correct of course that under the circumstances you describe the code
will fail. But that is no different from the scenario:

   "a new status is added, the code is not modified to handle it, 
    no tests are written to check the code is correct (or if the 
    tests are written, the test suite is not run), and then the 
    code is released at which point it fails"

We know that even the best programmer writes buggy code, which is why we
invent processes like defensive programming, design by contract, test
driven development, unit testing and so on. Even so, buggy code gets
written and released. When that happens, it is a failure of process. If
your process is so poor that you release code without running it with
asserts enabled, then assert will not save you from bugs. No process is
immune to sufficiently malicious or incompetent use.

Assertions are just a tool, not a panacea.



-- 
Steven

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

#80777

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 11/14/2014 03:33 AM, Steven D'Aprano wrote:
> 
> I agree with Marko in this case. Marko's example of defensive programming is very similar to the one I gave in my
> essay here:
> 
> http://import-that.dreamwidth.org/676.html
> 
> You're correct of course that under the circumstances you describe the code will fail. But that is no different
> from the scenario:
> 
> "a new status is added, the code is not modified to handle it, no tests are written to check the code is correct
> (or if the tests are written, the test suite is not run), and then the code is released at which point it fails"

I am reminded of a Star Treck episode (Deep Space 9?) in which a Klingon is mocking the Federation tech for having
three backups, instead of only two, to which the Federation tech replies, "When the second one fails, I wouldn't want
to be without my tertiary backup!"

My point being:  a safety net that is so easily disabled does not count (IMHO) as a backup.


> If your process is so poor that you release code without running it with asserts enabled, then assert will not save
> you from bugs.

This is one my very few complaints about Python:  running it normally is the same as running with DEBUG turned on, so
the unusual case is remembering to run with asserts turned /off/.


> Assertions are just a tool, not a panacea.

Right -- and using it is like using a rock when what you need is a ball-peen hammer.  ;)

- --
~Ethan~
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)

iQIcBAEBAgAGBQJUZkdzAAoJENZ7D1rrH75Nl9YQALx9UIAxYzlzH04EoMlILErb
0wz5xNhTM2JmF3csJPi3pQSpEr1XpHhWjFZYsFoPB24I8bN7tGALb91+ME7ElHgw
WP6Z+AVPuHCRxTG/oteK72+f5S+SN6zV1ECwrUuWxqIt5CHzYFtQjRKvEinNDtaT
xKtEfYZdrZFeqo7ssV2gHprDd1QFIAygLMbIlwke6nT/TdMGmw/wG9LQtpfSnrQc
4BeFoeYM3OL+hxHUNfYJI9cGL7skykU3EHnuFqNbhA6QhGawvBqUhVDGoFFDkJ/e
AX6AGk5Fu9cvjEFTzRQJzW4S5s6nD4dYM7Z93GfD9G9KBmfzQNM1pBA3yqxf0S8Q
CWTWBs8pPkYe/G1Y/WOn7lzYQdMneIGUNnHR8fnABKPPf5IeTXabkWgtVnq1g5Ty
DVcg/47G8gBMOTz5DD08iigu4f2bsNGowFoAkCDsbNmzjmxODGSUoj1ph/4xg6HP
HbuEQZXwNZXmlP9ZcLoxjCKdBdRJo3JZ4hAf6kVj4VT4y438GL2dI0/KIUSDWgYE
B0mCsQ7WYm80AvfpYR7fJoZsd/5jXe7RCLHanNLIZff3LupdFZri5E246KloUBj+
3Jw3HgwME6wyDshiHtsS5tuDcANvow+PICA+wn2KmU9Mn2JNwsG3D98ZFJfXp0JR
eG/Pg7cgQhrjhFqe6cgO
=EoEX
-----END PGP SIGNATURE-----

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

#80778

Ethan Furman <ethan@stoneleaf.us>:

> My point being: a safety net that is so easily disabled does not count
> (IMHO) as a backup.

Correct. You never lean on assertions. They are primarily formal
comments.

However, assertion failures do help in troubleshooting occasionally.
Most importantly, they immediately, unquestionably point the finger at
the developer.

> This is one my very few complaints about Python: running it normally
> is the same as running with DEBUG turned on, so the unusual case is
> remembering to run with asserts turned /off/.

I don't remember ever having optimized them out in any programming
language. Has that really improved the performance of your code?


Marko

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

#80781

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 11/14/2014 11:12 AM, Marko Rauhamaa wrote:
> Ethan Furman wrote:
> 
>> My point being: a safety net that is so easily disabled does not count (IMHO) as a backup.
> 
> Correct. You never lean on assertions. They are primarily formal comments.

On this point we can agree.  :)


>> This is one my very few complaints about Python: running it normally is the same as running with DEBUG turned
>> on, so the unusual case is remembering to run with asserts turned /off/.
> 
> I don't remember ever having optimized them out in any programming language. Has that really improved the 
> performance of your code?

In the handful of languages I have worked with so far, it's the other way 'round:  you un-optimize debug mode in.
CPython itself is a good example: when configuring, you must add --with-pydebug in order to get all the extra checks
added (which is great when adding new features), but that option isn't used when making production CPythons; yet
Python the language is just the opposite: debug mode is on /by default/, and to turn it off you have to specify -O:

$ ./python -c "print(__debug__)"
True

$ ./python -O -c "print(__debug__)"
False

- --
~Ethan~
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)

iQIcBAEBAgAGBQJUZmjlAAoJENZ7D1rrH75N3wMP/j9AowuuEvW9khTFX512QUHn
VGwEqkIu4FDFRA8T+qzwqhL7st5GGsnXaPvaWCLmPGbtt1qrVxJ1M6LLkuSWI8Fj
/hGe5rcEPP88/tMA5zy/pmg6jDgl96hojCnDmmS6meIQijVRpxMUGQ/4+N1oKI5d
JYKOlhFStk0N5O6gyZ3Yc6UDY+I9kLVPZsIgH0bXx5IkvwQUi1aNboADehDgSbM5
XDCuZvfNsauKyJZL52NkKu6qLSY/CHDx4kaWdP/i75gZPeVJirjEUkcLYSK6iE19
DpkyeR5wetH1yppH27yyfZPCKHnaYD8O/rykRrQLaIYefKb7XhxGWXa4C17w+AQP
3+hjONiPBsXe2FZZNTskKufI88oXbFwTyI3GseeWTIbS+V9TIwGTjZA+V9jc6EvL
T6T9PRGwOzfPolcLZ43x3ea8uCzLhxe0BILEfdmv6XPoPl9sJ5wHhbxg0oblo8GL
GNkfOFw0ncxplyobU0RXhvsKCUg6EpAukWgIcX5IhHfnesoS1BpSMtZubAbY4GVI
AHzL34KpYhOIDo3Ws26dCtHz5ocJSnDlHv2lxv+iEEZV+4lShFEreqfCLK0hcJTP
QMFoI401Dy3bLd3wJX9mYQA+nMGhNtRK+4uYwGSbAinOGDKVuqrmNM7wCaF9lr/I
aC+wno9PzNxkDNy2nUpY
=gJhZ
-----END PGP SIGNATURE-----

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

#80782

Ethan Furman <ethan@stoneleaf.us>:

> Python the language is just the opposite: debug mode is on /by
> default/, and to turn it off you have to specify -O:

C's the same way.

When I did Java, we enabled assertions in production code.


Marko

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

#80804

Ethan Furman wrote:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> On 11/14/2014 03:33 AM, Steven D'Aprano wrote:
>> 
>> I agree with Marko in this case. Marko's example of defensive programming
>> is very similar to the one I gave in my essay here:
>> 
>> http://import-that.dreamwidth.org/676.html
>> 
>> You're correct of course that under the circumstances you describe the
>> code will fail. But that is no different from the scenario:
>> 
>> "a new status is added, the code is not modified to handle it, no tests
>> are written to check the code is correct (or if the tests are written,
>> the test suite is not run), and then the code is released at which point
>> it fails"
> 
> I am reminded of a Star Treck episode (Deep Space 9?) in which a Klingon
> is mocking the Federation tech for having three backups, instead of only
> two, to which the Federation tech replies, "When the second one fails, I
> wouldn't want to be without my tertiary backup!"
> 
> My point being:  a safety net that is so easily disabled does not count
> (IMHO) as a backup.

Assertions are not a backup or a safety net. They are development tools,
like functional requirements, unit tests, code review and the use of
version control. Like any tool, you need to use it correctly. Writing
assertions but never actually running them is not correct use of
assertions, just like writing tests but never actually running them is not
correct use of tests.

One wouldn't say that code review by a senior developer before code is
checked into the main branch is pointless because "if the developer doesn't
perform the review, buggy code might be checked in". Well duh.

>> If your process is so poor that you release code without running it with
>> asserts enabled, then assert will not save you from bugs.
> 
> This is one my very few complaints about Python:  running it normally is
> the same as running with DEBUG turned on, so the unusual case is
> remembering to run with asserts turned /off/.

That's curious. Your complaint is that asserts are too easy to disable,
nevertheless it takes a deliberate and conscious act to disable them. By
default, Python runs assertions. And yet that is your complaint, so I
suppose that you would rather asserts *didn't* run by default and you
needed a deliberate act to run in debug mode. That doesn't seem consistent
to me.


>> Assertions are just a tool, not a panacea.
> 
> Right -- and using it is like using a rock when what you need is a
> ball-peen hammer.  ;)

Compared to Eiffel, Python doesn't have a lot of flexibility to assertions.
You either run them all, or you run none of them. But the assertions
themselves can be as narrow or as broad as you like. It's just code, you
can do anything you like in it.


-- 
Steven

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

#80808

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 11/14/2014 06:58 PM, Steven D'Aprano wrote:
> Ethan Furman wrote:
>> 
>> My point being:  a safety net that is so easily disabled does not count (IMHO) as a backup.
> 
> Assertions are not a backup or a safety net. [...]

Would you be happier if I phrased that as: Defensive programming techniques that can be unknowingly disabled by the
end-user aren't very helpful?


>>> If your process is so poor that you release code without running it with asserts enabled, then assert will not
>>> save you from bugs.
>> 
>> This is one my very few complaints about Python:  running it normally is the same as running with DEBUG turned
>> on, so the unusual case is remembering to run with asserts turned /off/.
> 
> That's curious. Your complaint is that asserts are too easy to disable, nevertheless it takes a deliberate and
> conscious act to disable them.

And more likely they were disabled because somebody was trying to get more performance from the app, not because that
someone thought, "I know, I'll turn asserts off and see how badly I can corrupt all my data."

> By default, Python runs assertions. And yet that is your complaint, so I suppose that you would rather asserts
> *didn't* run by default and you needed a deliberate act to run in debug mode.

That is correct.

> That doesn't seem consistent to me.

Because debug mode runs by default, many folks (myself included) simply run everything in debug mode.  I have never
even considered, until this very moment, to run my unittests with -O.  And yet the very purpose of -O is to
(hopefully) get more performance.  So you end up with folks using asserts inappropriately, yet their tests pass.  They
distribute their code.  Somebody has a slower machine, or gobs of data, so they decide to use -O.  Asserts are
disabled, something somewhere isn't checked, an error passes silently, the wrong thing happens... I'll you use your
imagination for what happens next.

Having debug mode be the default makes it too easy to screw up.

And yes, I am aware of at least one very large, complex, and modular system that uses Python, Javascript, CSS, HTML,
and some templating language I don't remember the name of.  It allows for third-party module integration.  It checks
third-party code with asserts.  It checks user-input with asserts.

I strongly suspect that if debug mode was not the default, this particular abuse wouldn't happen nearly as frequently
as it does.

- --
~Ethan~
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)

iQIcBAEBAgAGBQJUZtIBAAoJENZ7D1rrH75NmJAP/jmW9GhlR2TeThlUoiIaslVU
qKgiUeNplab9rbbIfQigmZaSTh/n+CeSK9pCu5dIOz7m6oBGoqtWJGFIl+E7pAsz
+MWLCDCIzCi4AGslDZ3ZZSW+e1zG2EK2BgNtLuh3EV4fBJq9GSNDfzlsUbXO7qnQ
yO0h41QuFOMuPiXDGkZ979u5OOBoH1JRUjmXhfUOSua0YcJ1dyRxNJKyhsMyUYPn
relMcTyT04rXj/sl3LUFgaO898mV7ieKgB5tBybAg5EKpArzpnAeIgMjcTP8B6YH
f+2n0jyL56oCCA0CO4BWP31unD8v89hBBeVJo0weprS9owq8OAdfyjXdfYMM77sM
oeQjCM8rs7uej17l4joGfvkrAnsa1BQLyhWzk0aeH4xpfMkgLHVnbwRt6v2PvPWK
IxNraSQQm3UjL1o1trLVznxT2+TOnNUucAl0XSLWSnIo9H1NJmYBZdHpmXvfo7R5
qIo1MyrQYLful+iaNI1I+5A3KLrKOduHm6Uqf4mDKXX6hMMbOdT1lHHpuD/fJYWW
jNqOiMpZl3NtxuEJjdLc5mvXvkoTZ9Z188WfFvFNnsL27aGxFfuulAWKc6EpbWgW
+8VoXVVhgs1mcB4UHM5dFrRSG7CgZi+btfHEGympWv74zun9FHHu2hNg+XPDibtS
D5P2/nCwQYFuCgapy+Ko
=QH9H
-----END PGP SIGNATURE-----

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

#80950

Ethan Furman wrote:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> On 11/14/2014 06:58 PM, Steven D'Aprano wrote:
>> Ethan Furman wrote:
>>> 
>>> My point being:  a safety net that is so easily disabled does not count
>>> (IMHO) as a backup.
>> 
>> Assertions are not a backup or a safety net. [...]
> 
> Would you be happier if I phrased that as: Defensive programming
> techniques that can be unknowingly disabled by the end-user aren't very
> helpful?

No.

You appear to be labouring under the misapprehension that assertion-based
techniques (such as design by contract) are a technique for guarding
against expected errors in (say) data. If that were the case, then allowing
the end-user to disable such guards would be a bad idea. And that is one
reason (but not the only reason) why we should never use assert for "lazy
man's argument checking" of public library functions, or for validating
data.

# this is bad
positive_value = int(raw_input("Enter a positive integer: "))
assert positive_value > 0
blow_something_up_if_negative(positive_value)


But this is a misuse of assertions. If (generic) you is writing code like
that, PLEASE STOP, you're writing buggy code and giving assert a bad name.

Assertions should never be used to *enforce* correct behaviour. Assertions
are used for *verifying* correctness of the code, and they are a form of
runtime testing. The motto of Design By Contract might be "Trust, but
Verify".

Assertions are tests, not production code. They just happen to live inside
the production code, where they provide the additional benefits of checked
comments, validation of internal logic, and so on.

Since assertions are tests, the end-user should never, ever see an
AssertionError. If they do, it is a bug in your code. Since the end-user
will never see a failed assertion then it is harmless if they disable them.
At best it won't matter one whit, since your code is perfectly bug free[1].
At worst, they are no worse off than if you had neglected to write any
assertions at all.

But if they do run with assertions enabled, and one fails, then you, the
developer, get the bonus of "fail early, fail hard". Instead of the
undefined behaviour of buggy code, you get a nice clean assertion error
telling you what went wrong and where.



[1] Also on time and below budget.

-- 
Steven

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

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

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

csiph-web