On Nov 16, 7:28 am, Steve Holden <[EMAIL PROTECTED]> wrote: > George Sakkis wrote: > > On Nov 16, 2:05 am, Arnaud Delobelle <[EMAIL PROTECTED]> wrote: > > >> Steven D'Aprano <[EMAIL PROTECTED]> writes: > >>> On Sat, 15 Nov 2008 01:40:04 -0800, Rick Giuly wrote: > >>>> Hello All, > >>>> Why is python designed so that b and c (according to code below) > >>>> actually share the same list object? It seems more natural to me that > >>>> each object would be created with a new list object in the points > >>>> variable. > >>> That's not natural *at all*. You're initialising the argument "points" > >>> with the same list every time. If you wanted it to have a different list > >>> each time, you should have said so. Don't blame the language for doing > >>> exactly what you told it to do. > >> Come on. The fact that this questions comes up so often (twice in 24h) > >> is proof that this is a surprising behaviour. I do think it is the > >> correct one but it is very natural to assume that when you write > > >> def foo(bar=[]): > >> bar.append(6) > >> ... > > >> you are describing what happens when you _call_ foo, i.e.: > > >> 1. if bar is not provided, make it equal to [] > >> 2. Append 6 to bar > >> 3. ... > > > +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? > > > 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. However I can see > far more justification for the behavior Python currently exhibits than > the semantic time-bomb you are proposing.
It is too bad you are not better at sharing what you see. I would like to see 'far more' of it, if it's there. -- http://mail.python.org/mailman/listinfo/python-list
