Path: csiph.com!v102.xanadu-bbs.net!xanadu-bbs.net!feeder.erje.net!eu.feeder.erje.net!newsfeed.xs4all.nl!newsfeed1.news.xs4all.nl!xs4all!newsgate.cistron.nl!newsgate.news.xs4all.nl!post.news.xs4all.nl!not-for-mail Return-Path: X-Original-To: python-list@python.org Delivered-To: python-list@mail.python.org X-Spam-Status: OK 0.041 X-Spam-Evidence: '*H*': 0.92; '*S*': 0.00; '"this': 0.03; 'contexts': 0.09; 'executes': 0.09; 'statements': 0.09; 'tests,': 0.09; 'python': 0.11; 'bug': 0.12; 'systems.': 0.12; '"an': 0.16; 'oracle.': 0.16; 'pythonistas': 0.16; 'substitute': 0.16; 'variants': 0.16; 'wider': 0.16; 'exception': 0.16; 'wrote:': 0.18; 'all,': 0.19; 'not,': 0.20; 'written': 0.21; 'code,': 0.22; 'coding': 0.22; 'email addr:gmail.com>': 0.22; 'tests': 0.22; 'to:name:python-list@python.org': 0.22; "aren't": 0.24; 'driver': 0.24; 'removed.': 0.24; 'test.': 0.24; 'chapter': 0.26; 'compare': 0.26; 'first,': 0.26; 'code:': 0.26; 'header:In-Reply-To:1': 0.27; 'function': 0.29; 'testing': 0.29; 'correct': 0.29; 'rest': 0.29; 'leave': 0.29; '[1]': 0.29; 'am,': 0.29; "doesn't": 0.30; '[2]': 0.30; 'especially': 0.30; 'message-id:@mail.gmail.com': 0.30; 'code': 0.31; 'assert': 0.31; 'extending': 0.31; 'piece': 0.31; 'second,': 0.31; 'file': 0.32; 'extend': 0.32; 'maintaining': 0.32; 'run': 0.32; 'says': 0.33; 'framework': 0.33; 'problem': 0.35; 'basic': 0.35; 'test': 0.35; 'but': 0.35; 'received:google.com': 0.35; 'there': 0.35; 'impression': 0.36; 'useful': 0.36; 'should': 0.36; 'half': 0.37; 'integration': 0.37; 'unit': 0.37; 'application': 0.37; 'two': 0.37; 'architecture': 0.38; 'skip:& 10': 0.38; 'feed': 0.38; 'nov': 0.38; 'to:addr :python-list': 0.38; 'expect': 0.39; 'to:addr:python.org': 0.39; 'even': 0.60; 'truly': 0.60; 'most': 0.60; 'introduced': 0.61; 'range': 0.61; 'such': 0.63; 'more': 0.64; 'great': 0.65; 'url:pdf': 0.68; 'beat': 0.68; 'results': 0.69; 'to,': 0.72; '"active': 0.84; '10:': 0.84; '15:': 0.84; 'action.': 0.84; 'it’s': 0.84; 'that’s': 0.84; 'that."': 0.84; 'url:documents': 0.84; 'am.': 0.91; 'passive': 0.91; 'assess': 0.96 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :content-type; bh=59Jl+rIziEKqIOzkKLTa7ZM3lvvURHTt5YTP4juasvo=; b=DYRXbwmcvKcrGQ/Vl1exdXo6JcZ4HiXokIxFP1eZCU14kcV55oL2BdW1USfDhlgzQj +hRP1Go+ERygmKa8FxkTj0IEmRfi8mtmb5iCc1zRCsj87LEWu0+s1HHamVvkvB9nMA0W 40XF0ZHcilX6Dzhg14ZwpFOKbVKJ/B97mJUNGY4+8btdi2wMkUrFBXsGvMFXhRA8wAS4 0WGRzKX4sB9w2KNsefsgZ3BL5z0mBSpSRhR9cxJYTajRxVCLJDbWSvUFOjnuSmo8uV8p h9Y8GeTjpSxltwxkQ1I9MzKYrgilgn29upc/ocwogjkWBpcO0CbjpAnnAxJd8aST7kUs th3A== X-Received: by 10.180.218.133 with SMTP id pg5mr49107447wic.70.1417080198158; Thu, 27 Nov 2014 01:23:18 -0800 (PST) MIME-Version: 1.0 In-Reply-To: <96c138e4-ab95-4e5f-a0c8-e696b5a926bb@googlegroups.com> References: <96c138e4-ab95-4e5f-a0c8-e696b5a926bb@googlegroups.com> From: TP Date: Thu, 27 Nov 2014 01:22:37 -0800 Subject: Re: I love assert To: "python-list@python.org" Content-Type: multipart/alternative; boundary=001a1135eac2d45d990508d3b193 X-BeenThere: python-list@python.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: General discussion list for the Python programming language List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Newsgroups: comp.lang.python Message-ID: Lines: 125 NNTP-Posting-Host: 2001:888:2000:d::a6 X-Trace: 1417080206 news.xs4all.nl 2953 [2001:888:2000:d::a6]:57054 X-Complaints-To: abuse@xs4all.nl Xref: csiph.com comp.lang.python:81620 --001a1135eac2d45d990508d3b193 Content-Type: text/plain; charset=ISO-8859-1 On Tue, Nov 11, 2014 at 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". > 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 --001a1135eac2d45d990508d3b193 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Tue, Nov 11, 20= 14 at 11:40 AM, Peter Cacioppi <peter.cacioppi@gmail.com> wrote:
I get the = impression that most Pythonistas aren't as habituated with assert state= ments 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 exceptio= n responsibilities, and, most of all, it should be used for passive inspect= ion 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:
<= br>"When I look at most unit tests — especially those written wi= th JUnit — they are assertions in disguise. When I write a great piec= e of software I sprinkle it with assertions that describe promises that I e= xpect the callers of my functions to live up to, as well as promises that f= unction makes to its clients. Those assertions evolve in the same artefact = as the rest of my code."

page 16:

"An even more pro= fessional approach is to leave the assertions in the code when you ship, an= d 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-tole= rance architecture on high-availability systems. This solves the problem of= maintaining a lot of extra software modules that assess execution and chec= k for correct behavior; that’s one half of a unit test. The other hal= f is the driver that executes the code: count on your stress tests, integra= tion tests, and system tests to do that."

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

&quo= t;This argumentation, of course, is just an alternative justification for t= he use of assertions in the code, as we already introduced in Chapter 1. As= sertions are powerful unit-level guards that beat most unit tests in two wa= ys. First, each one can do the job of a large number (conceivably, infinite= ) of scenario-based unit tests that compare computational results to an ora= cle. Second, they extend the run time of the test over a much wider range o= f contexts and detailed scenario variants by extending the test into the li= fetime 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

--001a1135eac2d45d990508d3b193--