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