Re: Pre/Postconditions with decorators

2005-01-09 Thread Andrew Dalke
Paul Rubin wrote: > [Type checking] should be left on. Leaving it in for development > and turning it off for production is like wearing a parachute > during ground training and taking it off once you're in the air. Why isn't it like practicing the trapeze with a net but going without a net when

Re: Pre/Postconditions with decorators

2005-01-09 Thread George Sakkis
"Stephen Thorne" <[EMAIL PROTECTED]> wrote: > Unresolved Problems: > 1) How do you handle duck types, i.e. a method that accepts StringIO, > cStringIO or any other object that has a .readlines(), .seek() and > .read() method? I think the 'proper' way of checking duck types (among other things) is

Re: Pre/Postconditions with decorators

2005-01-09 Thread rittersporn
Thank you very much for reminding me. I have been sloppy. It should have said static type checking. ciao Skip Montanaro wrote: > >> Eiffel (language) has both type checking and design by contract. > >> Python lacks both. > > Actually, Python is strongly typed. It's just dynamically instead o

Re: Pre/Postconditions with decorators

2005-01-09 Thread Paul Rubin
Stephen Thorne <[EMAIL PROTECTED]> writes: > > It should be left on. Leaving it in for development and turning it > > off for production is like wearing a parachute during ground training > > and taking it off once you're in the air. > So we can't use this for a case where we have an extremely lar

Re: Pre/Postconditions with decorators

2005-01-09 Thread Stephen Thorne
On 08 Jan 2005 15:50:48 -0800, Paul Rubin <"http://phr.cx"@nospam.invalid> wrote: > Stephen Thorne <[EMAIL PROTECTED]> writes: > > Unresolved Problems: > > 1) How do you handle duck types, i.e. a method that accepts StringIO, > > cStringIO or any other object that has a .readlines(), .seek() and >

Re: Pre/Postconditions with decorators

2005-01-08 Thread Paul Rubin
Stephen Thorne <[EMAIL PROTECTED]> writes: > Unresolved Problems: > 1) How do you handle duck types, i.e. a method that accepts StringIO, > cStringIO or any other object that has a .readlines(), .seek() and > .read() method? That should really be done through having those classes inherit a file-op

Re: Pre/Postconditions with decorators

2005-01-08 Thread Stephen Thorne
On Fri, 7 Jan 2005 20:01:50 +0200, George Sakkis <[EMAIL PROTECTED]> wrote: > > Hi George, > > it would be nice to see how you have tackled > > the task. > > Maybe we will have a checker > > module in Python one day... ;-) > > I posted my module on http://rafb.net/paste/results/voZYTG78.html and i

Re: Pre/Postconditions with decorators

2005-01-08 Thread Skip Montanaro
>> Eiffel (language) has both type checking and design by contract. >> Python lacks both. Actually, Python is strongly typed. It's just dynamically instead of statically typed. Skip -- http://mail.python.org/mailman/listinfo/python-list

Re: Pre/Postconditions with decorators

2005-01-08 Thread rittersporn
Thank you very much. It is really a very elegant piece of code :-) Eiffel (language) has both type checking and design by contract. Python lacks both. Your module tackles type checking, I tried to execute arbitrary code before and after function execution to realize runtime assertions. I wonder i

Re: Pre/Postconditions with decorators

2005-01-07 Thread George Sakkis
> Hi George, > it would be nice to see how you have tackled > the task. > Maybe we will have a checker > module in Python one day... ;-) I posted my module on http://rafb.net/paste/results/voZYTG78.html and its unit test on http://rafb.net/paste/results/MYxMQW95.html. Any feedback will be appreci

_Re Pre/Postconditions with decorators

2005-01-07 Thread Rittersporn
# Google-News won't let be post a follow-up right now! # Google-Beta-News destroys the formatting :-( # So I'll start a new thread. Hi Stephen I have not read anything about the "framehack lambda replacement" yet, but I do compile the pre- and postconditions. Syntax erros e.g. will be raised if th

Re: Pre/Postconditions with decorators

2005-01-07 Thread rittersporn
Hi Stephen I have not read anything about the "framehack lambda replacement" yet, but I do compile the pre- and postconditions. Syntax erros e.g. will be raised if the module is compiled. Although I must admit that your code snippets look more like compiled code ;-) Hi Robert thanks for the link t

Re: Pre/Postconditions with decorators

2005-01-07 Thread George Sakkis
"Robert Brewer" <[EMAIL PROTECTED]> wrote: > Ian Bicking was just talking about @require decorators: > http://blog.ianbicking.org/already-under-our-noses.html > > @require(int, int) > def gcd(a, b): > ... > > If we made a "checker" module for such things in the stdlib, we could > write most of

RE: Pre/Postconditions with decorators

2005-01-06 Thread Robert Brewer
Stephen Thorne wrote: > On 6 Jan 2005 13:33:42 -0800, Rittersporn > <[EMAIL PROTECTED]> wrote: > > @condition("number>0 and number<2","result>=0") > > def sqrt(number): > > import math > > return math.sqrt(number) > > > > @condition("list(seq) is not None","sum(seq)==result") > >

Re: Pre/Postconditions with decorators

2005-01-06 Thread Stephen Thorne
On 6 Jan 2005 13:33:42 -0800, Rittersporn <[EMAIL PROTECTED]> wrote: > @condition("number>0 and number<2","result>=0") > def sqrt(number): > import math > return math.sqrt(number) > > @condition("list(seq) is not None","sum(seq)==result") > def my_sum(seq): > tmp=0 >

Pre/Postconditions with decorators

2005-01-06 Thread Rittersporn
My humble attempt to model pre/postconditions with decorators :-) It's also my first experiment with decorators. If you have any ideas or thoughts on how to improve the code snippet, I'll be happy to learn more. Enjoy :-) def condition(pretext,posttext=""):