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

Peter Jones pjones@redhat.com
Wed, 28 May 2003 16:55:56 -0400 (EDT)

Hi, I'm Peter. Long time listener, first time caller.

On Wed, 28 May 2003, Terence Way wrote:

> 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.

It seems like either of these methods of coping with legacy docstrings thwart your basic premises. Unless the well-formed nature of the contracts are enforced, it seems to be fairly difficult to e.g. randomly test a function.

What if the docstring fails to parse? I have to be listening to stderr to know that it didn't work. I then have to parse the message from stderr to figure out which function didn't work, and finally I have to somehow mark this function as not compliant, and ignore whatever results I get.

It really seems like you want them either "on" or "off", not "on, but it might fail in some silent or hard to trap way".

> 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.

The assertion that contracts don't belong in the core seems entirely seperate from the discussion of their place in docstrings or in real code.

That being said, you still haven't explained why contracts belong in docstrings (or in documentation in general). They are executable code;
why not treat them as such?

self.note(): where is the documentation on how to enable the behavior.

I suspect we have to know this before we can know which way is easier.

That being said, I really don't see how these contracts can be meaningful as part of a docstring without some better mechanism for handling old docstrings that have been ruled malformed. What's your reasoning against making them their own kind of block, like "try:"?

-- Peter