Default Parameters to function!
mwh21 at cam.ac.uk
Thu Mar 16 00:16:12 CET 2000
Timothy Docker <timd at macquarie.com.au> writes:
> Michael Hudson <mwh21 at cam.ac.uk> writes:
> > "Yuriy Gorvitovskiy" <yuriy at centricsoftware.com> writes:
> > > I want to make a request to the Python developers to change the way of
> > > default parameters initialization from "when function definition is
> > > executed" to "when function executed".
> > Loosely speaking, no chance. Too much code relies on this behaviour
> > (yes, that's perhaps a bed idea, but it's still true).
> How much code really relies on this behaviour?
Code that (ab)uses the current behaviour to get around the lack of
lexical closures or as an optimization method.
> The normal workaround
> for what people really want is as the manual suggests, ie:
> def f( x=None ):
> if x == None:
> x = 
> This would continue to work if defaults were evaluated at
> function application time. How much code is written like
> def f( x= ):
> x.append( 'vvv' )
> and expects to get the mutated value next time a default is needed?
> Not too much I suspect.
No, it's not code like that that would cause problems.
> > What do you want to do instead? Store little code objects for each
> > default argument and evaluate them each time? I guess efficiency was
> > the initial reason for this implementation.
> If the "code objects" for defaults were only evaluated as required,
> it's hard to see that things would be any slower that the first code
> snippet above (which evals code when a default is required).
If you do this:
then it might matter. I suspect you would run into cyclic reference
problems at some point, too.
> Is there any reason why this shouldn't be considered for python
> 3000? Just about everyone hits this sooner or later, suggesting that
> that the current behaviour is not the ideal one.
Python 3K, maybe (as hopefully it will do away with the reasons for
using the current behaviour, as welll as cutting and dicing in 5
very few people approach me in real life and insist on proving they are
drooling idiots. -- Erik Naggum, comp.lang.lisp
More information about the Python-list