status of Programming by Contract (PEP 316)?

[Chris Mellon]

On 8/30/07, Russ <uymqlp502 at sneakemail.com> wrote:
>
> > PEP 316 introduces new syntax for a limited use feature. That's pretty
> > much a no-starter, in my opinion, and past experience tends to bear
> > that out. Furthermore, it predates decorators  and context managers,
> > which give all the syntax support you need and let you move the actual
> > DBC features into a library. I can't remember if I mentioned this
> > before but I believe that Philip Ebys PEAK toolkit has some stuff you
> > could use for DBC.
>
> I don't see how you can avoid adding some new syntax, given that
> Python does not
> currently have syntax for specifying invariants and pre- and post-
> conditions. And if I am
> not mistaken, the new syntax would appear only in doc strings, not in
> the regular Python
> code itself. We're not really talking here about changing the core
> Python syntax itself,
> so I don't see it as a "non-starter." Anyone who chooses not to use
> would be completely
> unaffected.
>

I misread the pep as adding the identifiers into the actual python
syntax, not in the docstring. All the more reason to implement it as a
library, then. I actually think that decorators and context managers
would be nicer than special docstring syntax, but I recognize the
benefit of the doctest style approach.

> As far as I can tell, Terence Way has done a nice job of implementing
> design by contract for
> Python, but perhaps a better approach is possible. The advantage of
> making part of the
> core Python distribution is that it would get vetted more thoroughly.
>

Things get vetted *before* they get added to the core, not after.