[Python-Dev] Introduction

[Peter Jones]

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