On Sun, Nov 16, 2008 at 11:02 AM, George Sakkis <[EMAIL PROTECTED]> wrote: > On Nov 16, 8:28 am, Steve Holden <[EMAIL PROTECTED]> wrote: >> >> > +1. Understanding and accepting the current behavior (mainly because >> > of the extra performance penalty of evaluating the default expressions >> > on every call would incur) is one thing, claiming that it is somehow >> > natural is plain silly, as dozens of threads keep showing time and >> > time again. For better or for worse the current semantics will >> > probably stay forever but I wish Python grows at least a syntax to >> > make the expected semantics easier to express, something like: >> >> > def foo(bar=`[]`): >> > bar.append(6) >> >> > where `expr` would mean "evaluate the expression in the function >> > body". Apart from the obvious usage for mutable objects, an added >> > benefit would be to have default arguments that depend on previous >> > arguments: >> >> Would you also retain the context surrounding the function declaration >> so it's obvious how it will be evaluated, or would you limit the default >> values to expressions with no bound variables? > > No, all expressions would be allowed, and the semantics would be > identical to evaluating them in the function body; not context would > be necessary. > >> > def foo(x, y=`x*x`, z=`x+y`): >> > return x+y+z >> >> > as opposed to the more verbose and less obvious current hack: >> >> > def foo(x, y=None, z=None): >> > if y is None: y = x*x >> > if z is None: z = x+y >> > return x+y+z >> >> "Less obvious" is entirely in the mind of the reader. > > Without documentation or peeking into the function body, a None > default conveys little or no information, so I don't think it's just > in the mind of the reader. Do you find the following less obvious than > the current workaround ? > > from datetime import date > from timedelta import timedelta > > def make_reservation(customer, > checkin=`date.today()`, > checkout=`checkin+timedelta(days=3)`): > ... > > >> However I can see >> far more justification for the behavior Python currently exhibits than >> the semantic time-bomb you are proposing. > > I didn't propose replacing the current behavior (that would cause way > too much breakage), only adding a new syntax which is now invalid, so > one would have to specify it explicitly.
Minor FYI, but Guido has proscribed backticks ever being used in Python again. See http://www.python.org/dev/peps/pep-3099/ Cheers, Chris -- Follow the path of the Iguana... http://rebertia.com > > George > -- > http://mail.python.org/mailman/listinfo/python-list > -- http://mail.python.org/mailman/listinfo/python-list
