status of Programming by Contract (PEP 316)?

[Steve Holden]

Russ wrote:
> Steve Holden wrote:
> 
>> Frankly I am getting a little tired of they way you are unable to even
>> recognize that your readers may well have a sensible appreciation of the
>> difficulties about which you write. As has been pointed out already,
>> many readers here are extremely experienced programmers.
> 
>> You said in an earlier post "that's not an insult", but that isn't
>> really up to you to decide. If it gives offense then it probably is,
>> whether it was intended to do so or not. You don't seem to appreciate
>> the insulting nature of your tone, and calling people bozos is not
>> likely to endear you to most c.l.py readers since it comes off as arrogant.
> 
> You quoted what I wrote in reply to a personal attack against me, but
> you conveniently
> neglected to quote the original insult that I was replying to. OK,
> I'll concede that I shouldn't
> have replied to a personal insult with another insult, but why am I
> the only one at fault here
> rather than the guy who started it?
> 
You aren't, and if I wasn't being even-handed I apologize.

> Frankly, Mr. Holden, I'm getting a bit tired of the clannish behavior
> here, where
> "outsiders" like me are held to a higher standard than your "insider"
> friends. I don't know
> who you are, nor do I care what you and your little group think about
> me.
> 
Well that's a healthy attitude, but I am concerned that the Python 
community should be as welcoming as possible, so I don't like the fact 
that you feel you are being treated differently from anyone else.

> As for DbC or what I call "self-testing code," I have come to the
> (tentative) realization that
> it is easy to implement in current Python -- without resorting to the
> "decorators" hack.
> OK, maybe this should have been obvious to me from the
> start, but here goes:
> 
> All you really need to test the pre-conditions of a function
> is a call at the top of the function to another function that checks
> the inputs. To test the
> post-conditions, you just need a call at the bottom of the function,
> just before the return,
> that checks the return values. Those functions can also check the
> invariants. Then you
> define a global variable to switch all the self-test functions on or
> off at once.
> 
It does constrain functions to return only from the bottom of their 
code, though, which not all Python functions currently do. Though 
there's nothing to stop you putting the calls before every return.

> An advantage of this approach is that all the self tests can be put at
> the bottom of the file
> (or perhaps in another file) to reduce "clutter" in the primary code.
> 
> I'd still prefer PEP 316, but this seems like a reasonable
> alternative.
> 
> One suggestion I have for PEP 316 is to provide a way to place the
> self-test
> checks in a separate file to reduce clutter.
> 
That would be a sensible suggestion. It would also be possible to guard 
the lengthier tests with "if debug" to allow them to be omitted 
(presumably along with their imports with a little further effort in 
code organization) in (optimized) production mode where timings were 
critical.

This could allow the benefits of DbC and unit testing at the same time.

Putting the verification code into external functions does assume that 
global variables aren't used in the pre- and post-conditions, but I 
presume that's a part of the regime anyway.

regards
  Steve
-- 
Steve Holden        +1 571 484 6266   +1 800 494 3119
Holden Web LLC/Ltd           http://www.holdenweb.com
Skype: holdenweb      http://del.icio.us/steve.holden
--------------- Asciimercial ------------------
Get on the web: Blog, lens and tag the Internet
Many services currently offer free registration
----------- Thank You for Reading -------------