[Python-Dev] Introduction (original) (raw)

Terence Way terry@wayforward.net
Wed, 28 May 2003 15:37:14 -0400

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.