Optional parameter object re-used when instantiating multiple objects

[Rick Giuly]

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.

class Blob:
def __init__(self, points=[]):
self._points = points
b = Blob()
c = Blob()

b._points.appen d(1)
c._points.appen d(2)

print b._points

# this will show that b._points is the same object as c._points

[Aaron Brady]

On Nov 16, 8:16*pm, Aaron Brady <castiro...@gma il.comwrote:

On Nov 16, 12:52*am, Steven D'Aprano <st...@REMOVE-THIS-

I've given practical reasons why the
Python choice is better. If you want default argument to be created from
scratch when the function is called, you can get it with little
inconvenience, but the opposite isn't true. It is very difficult to get
static default arguments given a hypothetical Python where default
arguments are created from scratch. There's no simple, easy idiom that
will work. The best I can come up with is a convention:

I'm not so sure.

## Default evaluated at definition time. *(Current.)

# Static arg.
def f( a= [] ):
* ...

# Non-static arg.
def f( a= None ):
* if a is None: a= []

Oops. Forgot one, after the subsequent posts.

# Non-static arg.
@nonstatic( a= list )
def f( a ):
...

This can achieve the 'if a is None' effect. 'nonstatic' takes a
callable or a string, '@nonstatic( a= "[]" )'.

I don't see a way to achieve George Sakkis's example:

if y is None: y = x*x
if z is None: z = x+y

Without a change to the language (the other options don't need one).

#emulates 'def foo(x, y=`x*x`, z=`x+y`):'
@nonstatic( y= 'x*x' ) #illegal
@nonstatic( z= 'x+y' ) #illegal
def foo(x, y, z):
return x+y+z

[Rick Giuly]

Thanks to all for your replies

All things considered, I vote for evaluating the arguments at runtime
(each time the function is called). Good reasons for this have already
been mentioned so I won't repeat them. A programming language is a
user interface of sorts. (Pretty much all languages are logical so
"correctnes s" is not what I'm meaning to discuss - I'm thinking about
usability.) Python provides, for the most part, an *excellent* user
interface to the programmer. Why not make it even "better" by
evaluating the arguments each time the function is called? It will be
harder to change the language 10 years from now, so why not change it
now?

(By "better" I mean that over many years of time programmers will be
more productive because the language will be learned a bit faster with
a fewer surprises - and still retain its power.)

-Rick

On Nov 16, 10:28 pm, "Chris Rebert" <c...@rebertia. comwrote:

For the Nth time this year that this has come up, I'll point out yet
again that this issue has already been discussed to death before:

[Python-ideas] proto-PEP: Fixing Non-constant Default Argumentshttp://mail.python.org/pipermail/python-ideas/2007-January/000121.html

[Python-3000] pre-PEP: Default Argument Expressionshttp ://mail.python.org/pipermail/python-3000/2007-February/005704.html

Result: Evaluating the arguments at runtime rather than
definition-time was deemed too magical; the backward compatibility
issues make changes unlikely; it's hard to find an acceptable syntax.

But hey, if some people want to have another go at it, best of luck.

Cheers,
Chris
--
Follow the path of the Iguana...http://rebertia.com

On Sun, Nov 16, 2008 at 8:11 PM, alex23 <wuwe...@gmail. comwrote:

On Nov 17, 12:27 pm, Steve Holden <st...@holdenwe b.comwrote:

If multiple statements are needed to perform the
argument initialization, how would you then propose the problem should
be solved?

Why, with another function of course!

def f(x, y=`f_arg_comput ation(x)`): ...

Or my personal favourite:

def f(x, **`f_arg_comput ation(x)`): ...

Seriously, though, I agree with Steve; the function body -is- the
place for computation to occur.
--
http://mail.python.org/mailman/listinfo/python-list

[George Sakkis]

On Nov 19, 8:41*am, Rick Giuly <rgiuly.gr...@y ahoo.comwrote:

Python provides, for the most part, an *excellent* user
interface to the programmer. Why not make it even "better"
by evaluating the arguments each time the function is called?
It will be harder to change the language 10 years from now,
so why not change it now?

You probably messed up with your time machine; "now" is 2008, not
1991 ;-)

George

[Aaron Brady]

On Nov 19, 12:05*pm, Dennis Lee Bieber <[e-mail] com.comwrote:

>
* * * * I wouldn't expect a language like Ada to somehow re-evaluate a
default argument on each call; why would I expect Python to do such?

Lots of people do.

If you had a menu in a browser interface that had the items, say,
'Stop' and 'Reload', what would you expect to happen if you clicked on
them?

[alex23]

On Nov 20, 10:14*am, Aaron Brady <castiro...@gma il.comwrote:

If you had a menu in a browser interface that had the items, say,
'Stop' and 'Reload', what would you expect to happen if you clicked on
them?

If you had a keyword called 'def', which defined functions, would you
expect it to define said functions when it executed, or on each
function call?

[Aaron Brady]

On Nov 19, 7:58*pm, alex23 <wuwe...@gmail. comwrote:

On Nov 20, 10:14*am, Aaron Brady <castiro...@gma il.comwrote:

If you had a menu in a browser interface that had the items, say,
'Stop' and 'Reload', what would you expect to happen if you clicked on
them?

If you had a keyword called 'def', which defined functions, would you
expect it to define said functions when it executed, or on each
function call?

At first, I would expect it to define them at compile-time. Then,
when I learned there was no such thing, I would expect it to define
them at execute-time. What does that have to do with evaluating a
default argument?

[alex23]

On Nov 20, 10:42*pm, Aaron Brady <castiro...@gma il.comwrote:

At first, I would expect it to define them at compile-time. *Then,
when I learned there was no such thing, I would expect it to define
them at execute-time. *What does that have to do with evaluating a
default argument?

It has -everything- to do with it when we're talking about the
defining of functions, and certainly a lot more relevance than straw
man arguments on the behaviour of browser buttons.

You said that you "would expect it to define them at execute-time". So
is that when the interpreter first hits the def or when the
interpreter hits every single function call? Because I personally
consider it to clearly occur at the point of definition and not at the
point of calling.

[Aaron Brady]

On Nov 20, 5:54*pm, alex23 <wuwe...@gmail. comwrote:

On Nov 20, 10:42*pm, Aaron Brady <castiro...@gma il.comwrote:

At first, I would expect it to define them at compile-time. *Then,
when I learned there was no such thing, I would expect it to define
them at execute-time. *What does that have to do with evaluating a
default argument?

It has -everything- to do with it when we're talking about the
defining of functions, and certainly a lot more relevance than straw
man arguments on the behaviour of browser buttons.

You said that you "would expect it to define them at execute-time". So
is that when the interpreter first hits the def or when the
interpreter hits every single function call? Because I personally
consider it to clearly occur at the point of definition and not at the
point of calling.

Why, I would expect the interpreter to define the functions when it
first hits the def, that is, at the point of definition.

[Steven D'Aprano]

On Wed, 19 Nov 2008 10:05:23 -0800, Dennis Lee Bieber wrote:

Do you really want a "default" argument that changes value depending
upon actions performed in the /surrounding/ scope?

And if you do, it is easy to get:

default_y = "something"

def parrot(x, y=None):
if y is None:
y = default_y
--
Steven

[Steven D'Aprano]

On Wed, 19 Nov 2008 11:26:54 -0800, George Sakkis wrote:

On Nov 19, 1:05Â*pm, Dennis Lee Bieber <[e-mail] com.comwrote:

>On Wed, 19 Nov 2008 05:41:57 -0800 (PST), Rick Giuly
<rgiuly.gr...@ yahoo.comdeclai med the following in comp.lang.pytho n:

(By "better" I mean that over many years of time programmers will be
more productive because the language will be learned a bit faster
with a fewer surprises - and still retain its power.)

Â* Â* Â* Â* Your opinion... I'm sure there are some libraries out there
Â* Â* Â* Â* that
rely upon the current behavior

That's a straw man; of course they rely on it since they can. The same
would be even more true if the opposite behavior was selected from the
beginning, many more libraries would rely on it instead of (ab)using
None as default.

"Many more"? You're guessing. By memory, most uses in the standard
library for default values either use immutables (strings or ints), in
which case rebinding the default at runtime is irrelevant, or are using
None to trigger special behaviour. (Please feel free to go through the
std lib and verify my feeble memories.) The *specific* gotcha people are
complaining about only affects a tiny proportion of default values: in
practice, it is almost always either [] or {}.

It seems a waste to have Python pay the cost of re-evaluating all those
default=0 and default=None calls just to satisfy a small proportion of
users whose intuition about Python's behaviour happens to be wrong. Since
that intuition has real costs and the current behaviour has real
benefits, people should just learn the Python way.

(I'm sympathetic for requests for syntactic sugar to get runtime
evaluation of defaults. I'm not sympathetic at all for requests to change
the default behaviour.)

That's the only argument that may worth some merit. It's interesting
though that C++, a language much more obsessed with performance, picks
the runtime semantics:

You're not going to hold C++ up as a shining beacon of the right way to
do things, are you?

--
Steven