[Python-ideas] hookable assertions - to support testing utilities and debugging

[Donald Stufft]

> On Feb 19, 2015, at 6:32 AM, Nick Coghlan <ncoghlan at gmail.com> wrote:
> 
> On 19 February 2015 at 21:16, Ronny Pfannschmidt
> <opensource at ronnypfannschmidt.de> wrote:
>> 
>> Im aware, my intent is to standardize the mechanism and push it into the
>> language,
> 
> Unfortunately, you're faced with a lot of C programmers firmly of the
> opinion that if you care about whether or not a piece of code gets
> executed, you don't put it it in an assert statement. It's a giant
> flashing red sign that says "This code is just checking something that
> should always be true, you don't actually need to read it in order to
> understand what this code is doing, but the assumption it documents
> may be helpful if something is puzzling you".
> 
> So from my perspective (being one of the aforementioned C
> programmers), I see this question as not so much about the assert
> statement per se, but rather a more philosophical question:
> 
> * is testing code categorically different from production code?
> * if yes, should assert statements be handled differently in testing code?
> * if yes, how should that difference be communicated to readers and to
> the interpreter?
> 
> (FWIW, I'm personally inclined to answer the first two questions with
> "yes", but haven't got any ideas as far as the third one goes)
> 
> Making the behaviour of assert statements configurable attempts to
> duck those questions instead of answering them, so I don't see at as a
> particularly useful approach - it makes the language more complex
> without providing additional clarity, rather than figuring out how to
> encode a genuinely important categorical distinction between test code
> and production code into the design of the language.

Speaking as a not C programmer, I think the answers to the first two are
absolutely yes, and the third one I dunno, maybe some sort of top level
import like from __testing__ import real_assert or something.

I absolutely hate the unittest style of assertFoo, it’s a whole bunch of
methods that I can never remember the names of and I have to go look them
up. I think using the assert statement is completely logical for test code
and I believe you can see this by the fact all of the methods to do checks
in unittest are named “assert something”. I think it introduces extra cognitive
burden for new users to have to use a whole bunch of additional methods to
do assertions in tests TBH. The way py.test works composes nicely with the
same kinds of expressions that you’re going to need to learn to write any
meaningful Python, but the assertFoo methods are special cases that don’t.

---
Donald Stufft
PGP: 7C6B 7C5D 5E2B 6356 A926 F04F 6E3C BCE9 3372 DCFA

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 801 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://mail.python.org/pipermail/python-ideas/attachments/20150219/6f118080/attachment.sig>