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

#81620

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

In "Why Most Unit Testing is Waste" by James O Coplien [1] he says on page
10:

"However, as with most unit tests, it's better to make this an assertion
than to pepper your test framework with such checks."

page 15:

"When I look at most unit tests -- especially those written with JUnit --
they are assertions in disguise. When I write a great piece of software I
sprinkle it with assertions that describe promises that I expect the
callers of my functions to live up to, as well as promises that function
makes to its clients. Those assertions evolve in the same artefact as the
rest of my code."

page 16:

"An even more professional approach is to leave the assertions in the code
when you ship, and to automatically file a bug report on behalf of the end
user and perhaps to try to re-start the application every time an assertion
fails."

"Turn unit tests into assertions. Use them to feed your fault-tolerance
architecture on high-availability systems. This solves the problem of
maintaining a lot of extra software modules that assess execution and check
for correct behavior; that's one half of a unit test. The other half is the
driver that executes the code: count on your stress tests, integration
tests, and system tests to do that."

And in "Seque" by James O Coplien [2] he is even more emphatic on page 17:

"This argumentation, of course, is just an alternative justification for
the use of assertions in the code, as we already introduced in Chapter 1.
Assertions are powerful unit-level guards that beat most unit tests in two
ways. First, each one can do the job of a large number (conceivably,
infinite) of scenario-based unit tests that compare computational results
to an oracle. Second, they extend the run time of the test over a much
wider range of contexts and detailed scenario variants by extending the
test into the lifetime of the product."

[1] http://www.rbcs-us.com/documents/Why-Most-Unit-Testing-is-Waste.pdf

[2] http://www.rbcs-us.com/documents/Segue.pdf

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

#81621

On Thu, 27 Nov 2014 01:22:37 -0800, TP wrote:

> 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".
>>
>>
> In "Why Most Unit Testing is Waste" by James O Coplien [1] he says on
> page 10:
> 
> "However, as with most unit tests, it's better to make this an assertion
> than to pepper your test framework with such checks."
> 
> page 15:
> 
> "When I look at most unit tests -- especially those written with JUnit
> --
> they are assertions in disguise. When I write a great piece of software
> I sprinkle it with assertions that describe promises that I expect the
> callers of my functions to live up to, as well as promises that function
> makes to its clients. Those assertions evolve in the same artefact as
> the rest of my code."
> 
> page 16:
> 
> "An even more professional approach is to leave the assertions in the
> code when you ship, and to automatically file a bug report on behalf of
> the end user and perhaps to try to re-start the application every time
> an assertion fails."
> 
> "Turn unit tests into assertions. Use them to feed your fault-tolerance
> architecture on high-availability systems. This solves the problem of
> maintaining a lot of extra software modules that assess execution and
> check for correct behavior; that's one half of a unit test. The other
> half is the driver that executes the code: count on your stress tests,
> integration tests, and system tests to do that."
> 
> And in "Seque" by James O Coplien [2] he is even more emphatic on page
> 17:
> 
> "This argumentation, of course, is just an alternative justification for
> the use of assertions in the code, as we already introduced in Chapter
> 1.
> Assertions are powerful unit-level guards that beat most unit tests in
> two ways. First, each one can do the job of a large number (conceivably,
> infinite) of scenario-based unit tests that compare computational
> results to an oracle. Second, they extend the run time of the test over
> a much wider range of contexts and detailed scenario variants by
> extending the test into the lifetime of the product."
> 
And as may wiser people than me have already highlighted Assertions can 
be switched off in python which means they cannot be relied upon in 
production code invalidating the authors suggestion that they can 
automate bug reports & "Extend testing into the lifetime of the product"
 

-- 
The state of some commercial Un*x is more unsecure than any Linux box
without a root password...
	-- Bernd Eckenfels

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

#81706

alister wrote:

> And as may wiser people than me have already highlighted Assertions can
> be switched off in python which means they cannot be relied upon in
> production code invalidating the authors suggestion that they can
> automate bug reports & "Extend testing into the lifetime of the product"

I'm afraid that you appear to have missed the point of assertions as tests.
Since they should never be used to *enforce* correct behaviour, but only to
*verify* behaviour is correct (i.e. as a form of testing), it doesn't
matter if you disable them. If I turn them off, all that happens is that
the tests won't run *for me*. The software will still be just as correct,
or just as buggy, regardless of the assertions.

But not everyone will turn them off. Even if *everybody else* turns them
off, you, the developer of the software, surely won't[1] since you're not
an idiot. (Why write assertions only to never use them?) That means that
whenever you run your software during the process of development, your
assertions will run.

In a complex, rich software application, you may not have unit tests for
every possible path through the software. But if you put assertions at the
intersections of paths (e.g. at the top of each loop, or the entry and exit
of each function), then even if you don't have a unit test for a particular
path, at least the assertions will be there to provide limited testing. In
other words, correctly written assertions can provide simple but effective
test coverage of 100% of your application.

I stress that assertions aren't a replacement for unit testing, but they
compliment unit testing: assertions can help cover code missed by your unit
tests, and check that your unit tests are correct.

If the user of your application disables assertions, they will be no worse
off than if you didn't write those assertions at all. And if they enable
assertions, then they get extended testing throughout the lifetime of the
product *for free*.

(Well, perhaps not *quite* for free, since assertions do have some
performance cost. But very cheaply.)




[1] Thanks to Python defaulting to __debug__ = True, the problem is getting
people to remember to test their software with assertions disabled, not to
get them to enable them.


-- 
Steven

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

#81707

On 2014-11-29 01:30, Steven D'Aprano wrote:
[snip]
> I stress that assertions aren't a replacement for unit testing, but they
> compliment unit testing: assertions can help cover code missed by your unit
> tests, and check that your unit tests are correct.
>
[snip]

I think you meant "complement". :-)

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

#81716

MRAB wrote:

> On 2014-11-29 01:30, Steven D'Aprano wrote:
> [snip]
>> I stress that assertions aren't a replacement for unit testing, but they
>> compliment unit testing: assertions can help cover code missed by your
>> unit tests, and check that your unit tests are correct.
>>
> [snip]
> 
> I think you meant "complement". :-)

Somibody swappid thi i and e kiys on my kiboard.



-- 
Steven

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

#81717

On Sat, Nov 29, 2014 at 8:31 PM, Steven D'Aprano
<steve+comp.lang.python@pearwood.info> wrote:
> Somibody swappid thi i and e kiys on my kiboard.

You know the old rule. "I" before "E", except after "QW"...

ChrisA

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

#81721

On 2014-11-29 09:31, Steven D'Aprano wrote:
> MRAB wrote:
>
>> On 2014-11-29 01:30, Steven D'Aprano wrote:
>> [snip]
>>> I stress that assertions aren't a replacement for unit testing, but they
>>> compliment unit testing: assertions can help cover code missed by your
>>> unit tests, and check that your unit tests are correct.
>>>
>> [snip]
>>
>> I think you meant "complement". :-)
>
> Somibody swappid thi i and e kiys on my kiboard.
>
So you think it's spelled "complemint"? :-)

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

#81708

On Sat, Nov 29, 2014 at 1:56 PM, MRAB <python@mrabarnett.plus.com> wrote:
> On 2014-11-29 01:30, Steven D'Aprano wrote:
> [snip]
>>
>> I stress that assertions aren't a replacement for unit testing, but they
>> compliment unit testing: assertions can help cover code missed by your
>> unit
>> tests, and check that your unit tests are correct.
>>
> [snip]
>
> I think you meant "complement". :-)

assert "Unit tests are soooooo clever"

ChrisA

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

#81724

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

On 11/28/2014 05:30 PM, Steven D'Aprano wrote:
> alister wrote:
> 
>> And as may wiser people than me have already highlighted Assertions can
>> be switched off in python which means they cannot be relied upon in
>> production code invalidating the authors suggestion that they can
>> automate bug reports & "Extend testing into the lifetime of the product"
> 
> I'm afraid that you appear to have missed the point of assertions as tests.
> Since they should never be used to *enforce* correct behaviour, but only to
> *verify* behaviour is correct (i.e. as a form of testing), it doesn't
> matter if you disable them. If I turn them off, all that happens is that
> the tests won't run *for me*. The software will still be just as correct,
> or just as buggy, regardless of the assertions.

And you have missed the point that building an intricate error-reporting, program restarting framework on top of
'assert' is ridiculous.

--
~Ethan~

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

#81726

Ethan Furman wrote:

> On 11/28/2014 05:30 PM, Steven D'Aprano wrote:
>> alister wrote:
>> 
>>> And as may wiser people than me have already highlighted Assertions can
>>> be switched off in python which means they cannot be relied upon in
>>> production code invalidating the authors suggestion that they can
>>> automate bug reports & "Extend testing into the lifetime of the product"
>> 
>> I'm afraid that you appear to have missed the point of assertions as
>> tests. Since they should never be used to *enforce* correct behaviour,
>> but only to *verify* behaviour is correct (i.e. as a form of testing), it
>> doesn't matter if you disable them. If I turn them off, all that happens
>> is that the tests won't run *for me*. The software will still be just as
>> correct, or just as buggy, regardless of the assertions.
> 
> And you have missed the point that building an intricate error-reporting,
> program restarting framework on top of 'assert' is ridiculous.

You are absolutely correct, I did miss that point. I didn't even notice
anyone suggest building an intricate error-reporting, program restarting
framework, let alone that it should be built on top of assert. Who made
that suggestion?

To be frank, I don't even know what that would mean -- how do you build such
a framework on top of assert? That's like saying "on top of print", only
even less useful. print() at least can redirect output to a file. assert
can only do to things: nothing, or raise AssertionError.


Ah, wait, I see the reference. You're talking about the quote from James O
Coplien:

    "An even more professional approach is to leave the assertions 
    in the code when you ship, and to automatically file a bug report
    on behalf of the end user and perhaps to try to re-start the 
    application every time an assertion fails."


Sounds reasonable to me (modulo privacy considerations). Many modern
software already does this: Firefox, Windows, KDE all have forms of crash
reporting that will automatically submit bug reports to the developers for
you. And Firefox at least will try (and generally succeed) to automatically
restart after a crash.

I'm sure that this crash reporting software isn't built on top of assert.
That would be absurd. But whatever it is built from, once it exists, then
it ought to be entirely agnostic whether exceptions are raised by assert or
raise. Python already supports half of this: the logging module can
intercept unexpected exceptions (including AssertionError), log them, email
them, display them in a GUI window, or any other output method you should
like. Having an application catch AssertionError and then phone home to
automatically submit diagnostic information to the developer shouldn't be
terribly hard, although the privacy issues need to be considered.

The other part, restarting the application, may be appropriate for some apps
but not others. How you would technically do this, I'm not sure. You
probably need some sort of daemon process which respawns your app if it
dies.

Which reminds me of this:

http://www.csd.uwo.ca/~magi/personal/humour/Computer_Folklore/Robin%20Hood%20And%20Friar%20Tuck.html



-- 
Steven

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

#81736

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

On 11/30/2014 12:18 AM, Steven D'Aprano wrote:
> 
> Ah, wait, I see the reference. You're talking about the quote from James O
> Coplien:
> 
>     "An even more professional approach is to leave the assertions 
>     in the code when you ship, and to automatically file a bug report
>     on behalf of the end user and perhaps to try to re-start the 
>     application every time an assertion fails."
> 
> 
> Sounds reasonable to me (modulo privacy considerations). Many modern
> software already does this: Firefox, Windows, KDE all have forms of crash
> reporting that will automatically submit bug reports to the developers for
> you. And Firefox at least will try (and generally succeed) to automatically
> restart after a crash.

The error-catching/reporting/restarting framework is fine.  My assertion (pun intended) is that building that framework
on assert, which can be unknowingly disabled by the end-user, is foolish.

--
~Ethan~

[toc] | [prev] | [standalone]

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

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

csiph-web