[Python-Dev] Introduction

[Terence Way]

On Wednesday, May 28, 2003, at 02:23  PM, Phillip J. Eby wrote:

> 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.
>
Ack.  Oops.  I've sent it off to peps@python.org with the XXX, but 
posted
here with the 999.

> 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?
Um.  No thought given to that.  My first guess is: syntax errors printed
to standard error, optionally silently ignored, no safety checks 
installed
either way.  Run-time errors trapped and re-raised as some kind of
ContractViolation::

     def read_stuff(input)
         """pre: input.readline"""

would be valid, and the AttributeError would be wrapped inside a
PreconditionViolationError if the ``input`` parameter isn't some
type of input stream.

> 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?
Proposing that some implementation, hopefully mine, be put in the
standard library.  I *really* don't think contracts should be part of 
the
core syntax: contracts belong in the documentation, and changing all the
doc tools to parse code looking for contract assertions is harder than
building one or two docstring implementations.

self.note(): where *is* the documentation on how to enable 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.
Consider when Alice's preconditions work, but Bob's do not.  Code that
thinks it's calling Alice's code *must not* break when calling Bob's.
Weakening pre-conditions means that Alice's pre-conditions must be
tested as well: and Bob's code is run even if his pre-conditions fail.
The converse is also true: code that understands Bob's pre-conditions
must not fail even if Alice's pre-conditions fail.  This is tough to
do with asserts, or with incompatible contract packages.

I haven't made that clear in the PEP or the samples, and it needs to
be clear, because it is the /only/ reason why contracts need to be in
the language/standard runtime.

Excellent points, thanks for taking an interest.