473,704 Members | 2,846 Online
Bytes | Software Development & Data Engineering Community
+ Post

Home Posts Topics Members FAQ

status of Programming by Contract (PEP 316)?

I just stumbled onto PEP 316: Programming by Contract for Python
(http://www.python.org/dev/peps/pep-0316/). This would be a great
addition to Python, but I see that it was submitted way back in 2003,
and its status is "deferred." I did a quick search on
comp.lang.pytho n,
but I don't seem to see much on it. Does anyone know what the real
status is of getting this into standard Python? Thanks.

Aug 29 '07 #1
81 2777
Russ wrote:
I just stumbled onto PEP 316: Programming by Contract for Python
(http://www.python.org/dev/peps/pep-0316/). This would be a great
addition to Python, but I see that it was submitted way back in 2003,
and its status is "deferred." I did a quick search on
comp.lang.pytho n,
but I don't seem to see much on it. Does anyone know what the real
status is of getting this into standard Python? Thanks.
PEP's with "deferred" status typically aren't going into Python any time
soon, if ever. Since the due date for all Python 3 core changes is long
past due, you won't even be seeing it in Python 3.

Steve
Aug 29 '07 #2
On Aug 28, 9:35 pm, Steven Bethard <steven.beth... @gmail.comwrote :
Russ wrote:
I just stumbled onto PEP 316: Programming by Contract for Python
(http://www.python.org/dev/peps/pep-0316/). This would be a great
addition to Python, but I see that it was submitted way back in 2003,
and its status is "deferred." I did a quick search on
comp.lang.pytho n,
but I don't seem to see much on it. Does anyone know what the real
status is of getting this into standard Python? Thanks.

PEP's with "deferred" status typically aren't going into Python any time
soon, if ever. Since the due date for all Python 3 core changes is long
past due, you won't even be seeing it in Python 3.

Steve
Thanks for that information. That's too bad, because it seems like a
strong positive capability to add to Python. I wonder why the cold
reception. Were there problems with the idea itself or just the
implementation? Or is it just a low priority?

In any case, I guess it is still perfectly usable even if it isn't
part of the core Python. Has anyone used it? If so, how well did it
work? Thanks.

Aug 29 '07 #3
On Aug 29, 7:21 am, Russ <uymqlp...@snea kemail.comwrote :
>
Thanks for that information. That's too bad, because it seems like a
strong positive capability to add to Python. I wonder why the cold
reception. Were there problems with the idea itself or just the
implementation? Or is it just a low priority?
Why do you think that would ad a strong positive capability?
To me at least it seems a big fat lot of over-engineering, not
needed in 99% of programs. In the remaining 1%, it would still not
be needed since Python provides out of the box very powerful
metaprogramming capabilities so that you can implement
yourself the checks you need, if you really need them.
In any case, I guess it is still perfectly usable even if it isn't
part of the core Python. Has anyone used it? If so, how well did it
work? Thanks.
Dunno, I would be curious myself to know if there are users
of these frameworks (including AOP frameworks in Python) or
if they are just exercises.

Michele Simionato

Aug 29 '07 #4
On Aug 28, 10:58 pm, Michele Simionato <michele.simion ...@gmail.com>
wrote:
Why do you think that would ad a strong positive capability?
To me at least it seems a big fat lot of over-engineering, not
needed in 99% of programs. In the remaining 1%, it would still not
be needed since Python provides out of the box very powerful
metaprogramming capabilities so that you can implement
yourself the checks you need, if you really need them.
I get the strong impression you don't really understand what
programming by contract is.

I have not yet personally used it, but I am interested in anything
that can help to make my programs more reliable. If you are
programming something that doesn't really need to be correct, than you
probably don't need it. But if you really need (or want) your software
to be correct and reliable as possible, I think you you should be
interested in it. You might want to read this:

http://archive.eiffel.com/doc/manual...iane/page.html

Aug 29 '07 #5
On Aug 29, 8:45 am, Russ <uymqlp...@snea kemail.comwrote :
I get the strong impression you don't really understand what
programming by contract is.

I have not yet personally used it, but I am interested in anything
that can help to make my programs more reliable. If you are
programming something that doesn't really need to be correct, than you
probably don't need it. But if you really need (or want) your software
to be correct and reliable as possible, I think you you should be
interested in it. You might want to read this:

http://archive.eiffel.com/doc/manual...ct/ariane/page...
That paper contains only a good think: a link to the contrarian view
http://home.flash.net/~kennieg/ariane.html#s3.1.5

Aug 29 '07 #6
In article <11************ **********@z24g 2000prh.googleg roups.com>,
Russ <uy*******@snea kemail.comwrote :
>
I just stumbled onto PEP 316: Programming by Contract for Python
(http://www.python.org/dev/peps/pep-0316/). This would be a great
addition to Python, but I see that it was submitted way back in 2003,
and its status is "deferred." I did a quick search on comp.lang.pytho n,
but I don't seem to see much on it. Does anyone know what the real
status is of getting this into standard Python? Thanks.
The way to get this into Python is to get people to use it as a
stand-alone module. It's already in PyPI, so now it's time for some
marketing.
--
Aahz (aa**@pythoncra ft.com) <* http://www.pythoncraft.com/

"If you don't know what your program is supposed to do, you'd better not
start writing it." --Dijkstra
Aug 29 '07 #7
On Tue, 28 Aug 2007 23:45:28 -0700, Russ wrote:
On Aug 28, 10:58 pm, Michele Simionato <michele.simion ...@gmail.com>
wrote:
>Why do you think that would ad a strong positive capability?
To me at least it seems a big fat lot of over-engineering, not
needed in 99% of programs. In the remaining 1%, it would still not
be needed since Python provides out of the box very powerful
metaprogrammin g capabilities so that you can implement
yourself the checks you need, if you really need them.

I get the strong impression you don't really understand what
programming by contract is.

I have not yet personally used it, but I am interested in anything
that can help to make my programs more reliable. If you are
programming something that doesn't really need to be correct, than you
probably don't need it. But if you really need (or want) your software
to be correct and reliable as possible, I think you you should be
interested in it. You might want to read this:

http://archive.eiffel.com/doc/manual...iane/page.html
I agree with Chris - there's no need to be condescending.

However, I agree with you that this is a valuable addition to a language.

It's not that Eiffel, by having preconditions and postconditions, is doing
anything that cannot be done in python already.

It's more that by making these things a formal part of the language, or at
least a module that facilitates them, one gives a sort of stamp of
approval to adding a ton of assertions about how your code is supposed to
work /when/working/in/that/language, which makes debugging a relative
snap. Isn't that something people should want for python? Sturdy code
and easy debugging?

I've been trying to write my python code with tons of "unnecessar y" if
statements that check out my assumptions, and I'm finding more or less
what the Eiffel people claim: I'm investing a little bit of upfront time,
and getting a huge payoff in the backend as my code starts to debug
itself. But I likely never would've started taking my error checking to
such extremes if I hadn't been curious about Eiffel for a while.

Throwing in tons of error and assumption checking mostly eliminates silly
tracing from procedure to function to procedure to function, trying to
find the ultimate root cause of a problem. Usually, the root cause is
identified in an error on stderr or similar.

Keep in mind that debugging usually takes far longer than the initial
coding. Programming by contract seems to balance that out, relatively
speaking.

Granted, we could just say "You should check for these things anyway", or
"You should know what you're doing", but... Isn't that kind of what
assembler programmers used to say to Lisp, FORTRAN and COBOL programmers?

And what about the case where you've written a piece of code, and
someone else has written another, and the two pieces of code need to
interact? Odds are pretty good that if this code has much substance,
there'll be opportunity for subtly different assumptions about what should
be happening in each (yes, "well abstracted" code will be
misassumption-resistant, but even the best OOP programmers will run afoul
of this /sometimes/). Perhaps both these programmers "Know what they're
doing", but they don't necessarily know what the other is doing!

IMO, putting Programming by Contract into python as part of the language
itself, or as a simple module, is a little bit like a company or
department coming up with a mission statement. It's easy to say that it's
meaningless, and some will ignore it, but it still kind of sets the tone
for how things "should be done".
Aug 29 '07 #8
But it's always a good idea to make your software "correct and as
reliable as possible", isn't it? The problem is the external constraints
on the project. As the old saying goes: "Cheap, fast, reliable: choose
any two".
If you are suggesting that "programmin g by contract" is not
appropriate for every application, you will get no argument from me.
All I am suggesting is that having the option to use it when you need
it is very desirable, and it can possibly enhance the versatility of
Python by making Python more suitable for *some* mission-critical
applications.

I once read a book on something called SPARK Ada, which also supports
programming by contract. I was pleasantly surprised to discover
yesterday that support for the such methods is also available for
Python. However, the support would obviously be a bit stronger if it
were in the core Python distribution.

What I really like about the implementation I cited above is that the
invariants and the pre and post-conditions can all be put right in the
doc string at the beginning of each class or function. You can think
of it as a detailed specification of the intent (or of some of the
requirements or constraints) of the class or function -- which can be
*automatically* checked during testing. It can also be used for
explicit type checking.

It's like having some of your most critical unit tests built right
into your code. It may make your code very verbose, but it will also
be very complete.

Aug 29 '07 #9
On Aug 30, 1:17 am, Dan Stromberg - Datallegro
<dstromb...@dat allegro.comwrot e:
IMO, putting Programming by Contract into python as part of the language
itself, or as a simple module, is a little bit like a company or
department coming up with a mission statement. It's easy to say that it's
meaningless, and some will ignore it, but it still kind of sets the tone
for how things "should be done".
I disagree. IMO automatic testing is thousands of times better than
design by contract and Python has already all the support you need
(unittest, doctest, py.test, nose, ...)
Michele Simionato

Aug 30 '07 #10

This thread has been closed and replies have been disabled. Please start a new discussion.

By using Bytes.com and it's services, you agree to our Privacy Policy and Terms of Use.

To disable or enable advertisements and analytics tracking please visit the manage ads & tracking page.