[Python-Dev] Introduction

[Phillip J. Eby]

At 01:32 PM 5/28/03 -0400, Terence Way wrote:

>I read somewhere that the best way to build big Python callouses was
>to write a PEP.

Guess I'll start helping you work on the callouses, then.  :)


>   Here goes:
>     http://www.wayforward.net/pycontract/pep-0999.html

Please don't number a pre-PEP;  I believe PEP 1 recomends using 'XXX' until 
a PEP number has been assigned by the PEP editors.


>Programming by Contract for Python... pre-conditions, post-conditions,
>invariants, with all the Eiffel goodness like weakening pre-conditions
>and strengthening invariants and post-conditions on inheritance, and
>access to old values.  All from docstrings, like doctest.

A number of things aren't clear from your PEP.  For example, how would 
syntax errors in assertions be handled?  How is backward compatibility with 
existing docstrings that may use 'inv:' or 'pre:' to specify conditions 
informally?

Are you proposing that this be part of Python's core syntax?  If so, then 
why do it as docstrings?  Are you proposing instead that your 
implementation be part of the standard library?  If so, then where is the 
documentation for how a developer enables the behavior?

Also, I didn't find the motivation section convincing.  Your answer to "Why 
not have several different implementations, or let programmers implement 
their own assertions?" isn't actually a justification.  If Alice uses some 
package to wrap her methods with checks, I can weaken the preconditions in 
a subclass, by simply overriding the methods.  If I can't do that, then it 
is a weakness of the DBC package Alice used, or of Alice's package, not a 
weakness of Python.