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

#80632

Anton <anton.schattenfeld@gmail.com>:

> 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

You use asserts to boldly state that the asserted condition never fails.
If it should fail anyway, the world could come tumbling down and you
would hang your head in shame.

Asserts help the reader of the code understand why some possibilities
are not considered by the code. They are not considered because the
writer of the code asserts they are not really possible.

Asserts help not only lay the blame to the writer of the code but might
also make it easier to troubleshoot failures.

I use asserts sparingly, just like comments (which asserts are). I use
them to communicate nonobvious truths to the future maintainer of the
code.

For example, instead of

     # never reached

I will write

     assert False


Or I might indicate the exhaustion of possibilities:

     if status == OK:
         ...
     elif status == ERROR:
         ...
     else:
         assert status == WARNING
         ...


Marko

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

#80635

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.

--
~Ethan~

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

#80637

Ethan Furman <ethan@stoneleaf.us>:

> 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.

How would it be better if you removed the assert then?


Marko

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

#80640

On Wed, Nov 12, 2014 at 2:56 PM, Marko Rauhamaa <marko@pacujo.net> wrote:
> Ethan Furman <ethan@stoneleaf.us>:
>
>> 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.
>
> 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

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

#80643

On Wednesday, November 12, 2014 2:05:17 PM UTC-8, Ian wrote:
> On Wed, Nov 12, 2014 at 2:56 PM, Marko Rauhamaa wrote:
> > Ethan Furman:
> >
> >> 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.
> >
> > 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

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:

if status == OK:
    ...
elif status == ERROR:
    ...
elif status == WARNING:
    ...
else:
    raise RuntimeError("Unknown errorno")

Or if it is at the end of the function, then:

if status == OK:
    ...
elif status == ERROR:
    ...
elif status == WARNING:
    ...

raise RuntimeError("Unknown errorno")

unless there is a customer exception type I can use for this situation.

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

#80646

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.

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

#80650

On Wednesday, November 12, 2014 2:42:19 PM UTC-8, Ian wrote:
> On Wed, Nov 12, 2014 at 3:13 PM, Anton <an...@gmail.com> wrote:
> > 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.

Right, but the goal is not to make the CONFUSED status be handled without coding, but to be notified about an unknown status code and act accordingly.

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

#80653

Anton <anschatten@gmail.com>:

> Right, but the goal is not to make the CONFUSED status be handled
> without coding, but to be notified about an unknown status code and
> act accordingly.

Asserts are not about notification, checking or optimization. They are
about communicating what's going on in the programmer's mind. They are
comments.

So why use asserts instead of comments?

Asserts *could* help in fixing bugs:

  1. An assertion failure immediately, unambiguously, declares even to
     customer service representatives that this is a terrible bug and
     should be brought to R&D's attention instead of hazing the poor
     customer with standard questions ("have you updated?", "have you
     rebooted?").

  2. An assertion failure probably gives the developer an very good clue
     as to what has gone wrong. There is a good chance of quickly
     finding an accurate analysis and fix to the bug.


Marko

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

#80793

Marko Rauhamaa wrote:

> Asserts are not about notification, checking or optimization. They are
> about communicating what's going on in the programmer's mind. They are
> comments.

Assertions can be used for *all of these things*.

Assertions can be used for:

- checking internal program logic;
- testing pre- and post-conditions;
- testing program invariants;
- comments which are verified at runtime;



> So why use asserts instead of comments?

Not all comments can be replaced with an assertion, but some can:

# once we reach here, mylist has at least two items

is better turned into an assert:

assert len(mylist) >= 2


To someone who is fluent in Python, the assertion is as easy to read and
understandable as the English comment. And it has the added benefit that
the interpreter will verify that the comment is correct at runtime.
Verifying comments is important, since programmers are notorious for
ignoring comments and failing to update them:

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

Why would you choose a comment rather than an assertion? If the code is
performance critical, and the extra cost of the assertion is significant,
and you cannot reasonably run the code using -O to disable it, then a
comment might be better.


> Asserts *could* help in fixing bugs:
> 
>   1. An assertion failure immediately, unambiguously, declares even to
>      customer service representatives that this is a terrible bug and
>      should be brought to R&D's attention instead of hazing the poor
>      customer with standard questions ("have you updated?", "have you
>      rebooted?").

If only that were the case :-(


>   2. An assertion failure probably gives the developer an very good clue
>      as to what has gone wrong. There is a good chance of quickly
>      finding an accurate analysis and fix to the bug.

In general, it is desirable to have any eventual exception occur as soon as
possible to the ultimate cause of the exception. Assertions can aid in
that. Languages such as Eiffel provide a rich and powerful set of different
assertions, including:

    require
    ensure
    check
    debug
    invariant

The Eiffel manual is explicit about the correct use of assertions:

    It should be clear from the preceding discussion that contracts 
    are not a mechanism to test for special conditions, for example
    erroneous user input. For that purpose, the usual control 
    structures ( if deposit_sum > 0 then ...) are available, 
    complemented in applicable cases by the exception handling 
    mechanism reviewed next. An assertion is instead a correctness
    condition governing the relationship between two software modules
    (not a software module and a human, or a software module and an 
    external device). If sum is negative on entry to deposit, 
    violating the precondition, the culprit is some other software 
    element, whose author was not careful enough to observe the terms 
    of the deal. Bluntly:

    Rule -- Assertion Violation: A run-time assertion violation is 
    the manifestation of a bug.

    [...]

    That violations indicate bugs explains why it is legitimate to 
    enable or disable assertion monitoring through mere compilation 
    options: for a correct system -- one without bugs -- assertions 
    will always hold, so the compilation option makes no difference 
    to the semantics of the system.


https://docs.eiffel.com/book/method/et-design-contract-tm-assertions-and-exceptions



-- 
Steven

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

#80795

Steven D'Aprano <steve+comp.lang.python@pearwood.info>:

> Marko Rauhamaa wrote:
>
>> Asserts are not about notification, checking or optimization. They are
>> about communicating what's going on in the programmer's mind. They are
>> comments.
>
> Assertions can be used for *all of these things*.
>
> Assertions can be used for:
>
> - checking internal program logic;
> - testing pre- and post-conditions;
> - testing program invariants;
> - comments which are verified at runtime;

Most importantly, assertion failures are not supposed to be recovered
from (within the program). Assertion failures can result in the loss of
life and limb. They can result in database corruption. They can result
in monetary losses. They can result in smoke coming out of the monitor.

That's because the programmer is in no way prepared for the assertion to
fail and cannot rely on the assertions to really be checked.

IOW, assertions are not a mechanism for fault-tolerant programming.


Marko

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

#80797

On Sat, Nov 15, 2014 at 11:12 AM, Marko Rauhamaa <marko@pacujo.net> wrote:
> Most importantly, assertion failures are not supposed to be recovered
> from (within the program). Assertion failures can result in the loss of
> life and limb. They can result in database corruption. They can result
> in monetary losses. They can result in smoke coming out of the monitor.

Or, in theory, AssertionError just prevented any of the above from happening.

ChrisA

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

#80798

Chris Angelico <rosuav@gmail.com>:

> On Sat, Nov 15, 2014 at 11:12 AM, Marko Rauhamaa <marko@pacujo.net> wrote:
>> Most importantly, assertion failures are not supposed to be recovered
>> from (within the program). Assertion failures can result in the loss
>> of life and limb. They can result in database corruption. They can
>> result in monetary losses. They can result in smoke coming out of the
>> monitor.
>
> Or, in theory, AssertionError just prevented any of the above from
> happening.

I'd advice against catching AssertionError and trying to recover from it
within the program. You could catch it, log it and reraise it, but since
the failure modes could be completely unexpected (really, by
definition), I would move fault-tolerance outside the failing process
and try to restore a coherent reality from there.

Assertion errors are in the same class with CPython bugs, external
signals (say, SIGKILL), security breaches, hardware failures and the
like.

For expected failure modes, other exceptions are a suitable facility.


Marko

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

#80799

On Sat, Nov 15, 2014 at 12:30 PM, Marko Rauhamaa <marko@pacujo.net> wrote:
> Chris Angelico <rosuav@gmail.com>:
>
>> On Sat, Nov 15, 2014 at 11:12 AM, Marko Rauhamaa <marko@pacujo.net> wrote:
>>> Most importantly, assertion failures are not supposed to be recovered
>>> from (within the program). Assertion failures can result in the loss
>>> of life and limb. They can result in database corruption. They can
>>> result in monetary losses. They can result in smoke coming out of the
>>> monitor.
>>
>> Or, in theory, AssertionError just prevented any of the above from
>> happening.
>
> I'd advice against catching AssertionError and trying to recover from it
> within the program. You could catch it, log it and reraise it, but since
> the failure modes could be completely unexpected (really, by
> definition), I would move fault-tolerance outside the failing process
> and try to restore a coherent reality from there.

I agree - never catch it. But you should be able to prevent database corruption:

conn = establish_database_connection()
try:
    do_stuff()
finally:
    conn.rollback()

The raising of AssertionError anywhere inside do_stuff() will prevent
craziness from getting to the database, because it aborts the
execution. (You know, the way a royal pardon does.)

ChrisA

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

#80800

On 2014-11-15 12:48, Chris Angelico wrote:
> conn = establish_database_connection()
> try:
>     do_stuff()
> finally:
>     conn.rollback()

this sounds suspiciously like you'd never actually commit.  Do you
mean something like

  conn = establisth_database_connection()
  try:
    do_stuff(conn)
  except:
    conn.rollback()
    raise

instead?

I don't generally like bare excepts, but in this case, the exception
just gets re-raised, so I feel Less Bad™ about it (there's still the
case where the rollback call raises some alternate exception,
obfuscating the underlying root issue).

-tkc

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

#80801

On Sat, Nov 15, 2014 at 1:14 PM, Tim Chase
<python.list@tim.thechases.com> wrote:
> On 2014-11-15 12:48, Chris Angelico wrote:
>> conn = establish_database_connection()
>> try:
>>     do_stuff()
>> finally:
>>     conn.rollback()
>
> this sounds suspiciously like you'd never actually commit.  Do you
> mean something like
>
>   conn = establisth_database_connection()
>   try:
>     do_stuff(conn)
>   except:
>     conn.rollback()
>     raise

No; I prefer to have the commit be as close as possible to the code
that needs it done. So in this toy example, the commit would be inside
- maybe deep inside - do_stuff(). After committing, rolling back
wouldn't hurt.

ChrisA

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

#81719

In article <87a93tl07u.fsf@elektro.pacujo.net>,
Marko Rauhamaa  <marko@pacujo.net> wrote:
>Chris Angelico <rosuav@gmail.com>:
>
>> On Sat, Nov 15, 2014 at 11:12 AM, Marko Rauhamaa <marko@pacujo.net> wrote:
>>> Most importantly, assertion failures are not supposed to be recovered
>>> from (within the program). Assertion failures can result in the loss
>>> of life and limb. They can result in database corruption. They can
>>> result in monetary losses. They can result in smoke coming out of the
>>> monitor.
>>
>> Or, in theory, AssertionError just prevented any of the above from
>> happening.
>
>I'd advice against catching AssertionError and trying to recover from it
>within the program. You could catch it, log it and reraise it, but since
>the failure modes could be completely unexpected (really, by
>definition), I would move fault-tolerance outside the failing process
>and try to restore a coherent reality from there.
>
>Assertion errors are in the same class with CPython bugs, external
>signals (say, SIGKILL), security breaches, hardware failures and the
>like.
>
>For expected failure modes, other exceptions are a suitable facility.

I agree with you (also with your other posts) and I hate that disabling
asserts is considered a kind of "optimising".
Wasn't Dijkstra who said that while the ship is on the dock, we have
life vests on, and while we are at sea, the life vests stay on shore.

It is a defect in python that asserts are automatically removed with
a -O option. Maybe if there are six levels of optimization -O7 at
last would remove the asserts.
Then in the programmers manual of my company I would have:
"Programs are only allowed to use -O7 if there is a test that doing
so results in a substantial benefit in running time, and documented
as such."

And no: AssertionError is no exception to be thrown (such that an
irresponsible person might catch, or even ignore them.)

Indeed it should be treated like a parity fault in the memory of
a computer: don't drive because the brakes don't work.

And then Ben Finney wants us to remove the asserts as soon as
they are committed to source control. Please! It is a fallacy that
there are untested and tested, hence correct, programs.
There are just more or less tested, and more or less correct
programs.
If I deliver a program to source control it may not be solid.
If I give it a tag it is solid... until the company sets a junior
on it to add a feature. Then the assert may turn out to be
life saver, even literally.

>Marko
-- 
Albert van der Horst, UTRECHT,THE NETHERLANDS
Economic growth -- being exponential -- ultimately falters.
albert@spe&ar&c.xs4all.nl &=n http://home.hccnet.nl/a.w.m.van.der.horst

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

#80654

On Wed, Nov 12, 2014 at 3:48 PM, Anton <anschatten@gmail.com> wrote:
> On Wednesday, November 12, 2014 2:42:19 PM UTC-8, Ian wrote:
>> On Wed, Nov 12, 2014 at 3:13 PM, Anton <an...@gmail.com> wrote:
>> > 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.
>
> Right, but the goal is not to make the CONFUSED status be handled without coding, but to be notified about an unknown status code and act accordingly.

Sure, which is why you and I have both suggested raising a RuntimeError instead.

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

#80663

On Wednesday, November 12, 2014 3:03:18 PM UTC-8, Ian wrote:
> On Wed, Nov 12, 2014 at 3:48 PM, Anton <an..@gmail.com> wrote:
> Sure, which is why you and I have both suggested raising a RuntimeError instead.
Yeah, I actually read it after sending my response :)

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

#80656

On Thu, Nov 13, 2014 at 10:02 AM, Ian Kelly <ian.g.kelly@gmail.com> wrote:
> On Wed, Nov 12, 2014 at 3:48 PM, Anton <anschatten@gmail.com> wrote:
>> On Wednesday, November 12, 2014 2:42:19 PM UTC-8, Ian wrote:
>>> On Wed, Nov 12, 2014 at 3:13 PM, Anton <an...@gmail.com> wrote:
>>> > 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.
>>
>> Right, but the goal is not to make the CONFUSED status be handled without coding, but to be notified about an unknown status code and act accordingly.
>
> Sure, which is why you and I have both suggested raising a RuntimeError instead.

Or, in as many cases as possible, raise an implicit KeyError and save
yourself a lot of typing. Any time these kinds of elif trees can be
turned into dict lookups, you get non-assert error checking for free.

ChrisA

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

#80659

Chris Angelico <rosuav@gmail.com>:

> Or, in as many cases as possible, raise an implicit KeyError and save
> yourself a lot of typing. Any time these kinds of elif trees can be
> turned into dict lookups, you get non-assert error checking for free.

I agree that you shouldn't sprinkle asserts around the code. But
consider this example:

     count = next_size / len(choices)

The casual reader of the code might be left wondering if "choices" could
be zero-length and if the programmer had overlooked the possibility,
leading to a lengthy analysis and bewilderment.

However, the programmer could have played this frustration out already
in his head and written:

     assert len(choices) > 0
     count = next_size / len(choices)

or, equivalently:

     # here len(choices) > 0
     count = next_size / len(choices)

and the casual maintainer would be able to read on.


Marko

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

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

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

csiph-web