On 8/30/07, Russ <[EMAIL PROTECTED]> 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. -- http://mail.python.org/mailman/listinfo/python-list
