status of Programming by Contract (PEP 316)?

[Russ]

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

 

[Steven Bethard]

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

 

[Russ]

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.

 

[Michele Simionato]

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

 

[Russ]

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/manuals/technology/contract/ariane/page.html

 

[Michele Simionato]

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/manuals/technology/contract/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

 

[Aahz]

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

 

[Chris Mellon]

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

Don't be condescending.

I have not yet personally used it, but I am interested in anything
that can help to make my programs more reliable.

The entire issue of software reliability, exactly what metrics you
should use to measure it, and whether any specific technique results
in more of it are very much in debate. If you want to experiment with
these techniques, you can do so without them being in the Python core.
Python has all the support you need to play with them right now.

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:

You don't want your software to KILL BABIES, do you? If you don't want
your programs to KILL BABIES then you should use our technique, so you
don't KILL BABIES.

There are ways to make correct programs besides DBC. It may not even
help in the general case - just as with unit testing and type proving,
you're going to be limited by what you don't think to assert or
document or test, and I've seen no evidence that DBC is any better
than anything else at preventing unwritten assumptions.

 

[Steve Holden]

You don't want your software to KILL BABIES, do you? If you don't want
your programs to KILL BABIES then you should use our technique, so you
don't KILL BABIES.

There are ways to make correct programs besides DBC. It may not even
help in the general case - just as with unit testing and type proving,
you're going to be limited by what you don't think to assert or
document or test, and I've seen no evidence that DBC is any better
than anything else at preventing unwritten assumptions.

Personally I have found the best strategy to be KWYD: know what you're
doing. Your assertion that success of DBC relies on the competence of
the practitioner is indeed true, just as it is for all other
methodologies. The number of programmers who *don't* know what they are
doing and yet manage to find well-paid employment in mission-critical
system implementation is truly staggering.

If I can blow my own trumpet briefly, two customers (each using over 25
kLOC I have delivered over the years) ran for two years while I was away
in the UK without having to make a single support call. One of the
systems was actually locked in a cupboard all that time (though I have
since advised that client to at least apply OS patches to bring it up to
date).

This was achieved by defensive programming, understanding the user
requirements and just generally knowing what I was doing. Nevertheless I
would hesitate to write code for such demanding areas as real-time
rocket flight control, because I just don't think I'm that good. Very
few people are, and learning as you go can be disastrously expensive
when military and space projects are involved.

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

regards
Steve
--
Steve Holden +1 571 484 6266 +1 800 494 3119
Holden Web LLC/Ltd http://www.holdenweb.com
Skype: holdenweb http://del.icio.us/steve.holden
--------------- Asciimercial ------------------
Get on the web: Blog, lens and tag the Internet
Many services currently offer free registration
----------- Thank You for Reading -------------

 

[Dan Stromberg - Datallegro]

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/manuals/technology/contract/ariane/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 "unnecessary" 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".

 

[Russ]

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

 

[Michele Simionato]

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

 

[Russ]

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

In theory, anything you can verify with "design by contract" you can
also verify with unittest and the rest. However, "design by contract"
has a major practical advantage: if you have real (or simulated)
inputs available, you don't need to write a test driver or generate
test inputs for each class or function.

All you need to do is to run your program with the real (or simulated)
inputs, all the internal data that gets passed around between classes
and functions gets generated as usual, and everything gets tested
automatically. In other words, you are spared the potentially
considerable effort of generating and storing samples of all the
internal data that gets passed around internally.

You may want to do unit tests also, of course. Separate unit tests
will give you more control and allow you to test individual classes
and functions using a wider variety of inputs. But if your design by
contract is comprehensive (i.e., passing it guarantees correct
functioning of your code), then your unit tests can simply make use of
the tests already available in the design by contract. So you've done
no extra work in setting up the design by contract anyway.

Another significant advantage of "design by contract" is that the
tests are all right there in your source code, where they are much
less likely to get lost or ignored by subsequent programmers who need
to maintain the code. Relying on separate units tests is a bit like
relying on extended "comments" or design documents that are separate
from the code. Yes, those are certainly useful, but they do not
eliminate the need for comments in the code.

 

[Bruno Desthuilliers]

Russ a écrit :
(snip)

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.

class Parrot(object):
@pre(lambda x : x != 42)
@post(lambda result: result != 42)
@invariant(lambda self: self.x == 42)
def reliable_method(self, x):
# your code here
return something

 

[Bruno Desthuilliers]

Russ a écrit :

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

I get the strong impression you don't really understand how
condescending you are.

I have not yet personally used it,

You have no working experience with the concept, but you think it should
make it into Python's core ???

 

[Bruno Desthuilliers]

Russ a écrit :

That looks like new syntax to me.

It's the syntax for decorator functions, and it's not that new - it
cames with Python 2.4, released November 30, 2004.

Did I miss your point?

Yes.

 

[Bruno Desthuilliers]

Russ a écrit :

When someone writes something as ignorant as that, they need to be
called on it.

When someone writes something as arrogant as that, they need to be
called on it.

Michele obviously knows what DbC is (probably better than you do), and
he also knows Python enough to know why you don't need to add anything
to Python to have it.

So you can implement everything you need already in Python?

Talking about DbC ?

Yes, of
course,

"Yes, of course". A couple of decorator functions and you're done. It's
pretty trivial, and that's why Michele told you could implement it by
yourself.

(snip)

I don't need to use it to understand the concept. That has been
explained
brilliantly by the Eiffel and SPARK Ada folks.

FWIW, the "Eiffel and SPARK Ada folks" also "brilliantly explained" why
one can not hope to "write reliable programs" without strict static
declarative type-checking.

One needs to have working experience with a concept to know what it's
really worth. Too bad for you, you're too "smart" to understand this.

I am also smart enough

Yes, obviously really smart.

 

[Bruno Desthuilliers]

Russ a écrit :

After looking more carefully at your example, I don't think it is as
clean and logical as the
PEP 316 syntax.

Possibly not, but at least it's trivial to implement.

At first I thought that your pre and post-conditions
applied to the class,

Pre and post conditions applying to the class ? Now that's an
interesting concept. IIRC, Eiffels pre and post conditions only apply to
methods, and I fail to see how they could apply to a class. But since
you're an expert on the subject, I don't doubt you'll enlighten us ?

but now I realize that they apply to the function. I prefer to see the
conditions inside
the function in the doc string. That just seems more logical to me.

Not to me. Doc strings are not for implementation. But if you want to
implement a DbC module using doc strings, please do so.

With all due respect,
your proposal is interesting, but I think it overextends the "function
decorator" idea a bit.

Definitively not, on the contrary - that's *exactly* what decorators are
for. Else, they would be nothing more than HOFs, and there would be no
point in having this syntactic sugar.

(snip).

 

[Chris Mellon]

If you are suggesting that "programming 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.

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

If a well written contract library were to exist, and people were to
use it, and the author were interested, it would make a decent
candidate for inclusion in the standard library, and I wouldn't oppose
such a thing (for all my opinion is worth, ie essentially nothing).
The PEP 316 special syntax is another matter entirely.

The best way for this to happen is for you to find or write such a
library, and use it to write good code.

 

[Russ]

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.

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.