[Python-ideas] fixing mutable default argument values

[Josiah Carlson]

"Jan Kanis" <jan.kanis at phil.uu.nl> wrote:
> Other non-python stuff is taking my time, but I'll reply to this anyway.  
> Better late than never (in this case).
> 
> On Thu, 01 Feb 2007 16:19:00 +0100, Lucio Torre <lucio.torre at gmail.com>  
> wrote:
> 
> > On 1/31/07, Jan Kanis <jan.kanis at phil.uu.nl> wrote:
> >> >
> >> > Isnt the other argument the fact that always re evaluating will bring
> >> > similar gotchas?
> >>
> >> IMO, it won't. Caching will have to be implemented in a different way,  
> >> but
> >> that wouldn't really be a gotcha (except for python 2.x programmers who
> >> didn't read the "what's new in python 3.0")
> >>
> >
> > Maybe is better to annoy newbies that didnt read the python FAQ than
> > seasoned python 2.x programmers! :)
> 
> That statement I can agree with, but it isn't really applicable here. The  
> applicable statement reads: "Maybe it's better to annoy newbies that  
> didn't read the python FAQ than python 2.x programmers who don't know  
> anything about 3.0 and assume it's just another new version of python."
> And I don't agree with that one. :)
> 
> >>  If the
> >> function depends on other state I'd imagine that most of the time you'd
> >> want a change in state to be reflected in the functions default value.
> >>
> >> example:
> >> def foo(x = exec_sql("SELECT someval FROM defaults_table WHERE
> >> some_expr")):
> >>     # do something
> >>
> >
> > i was thinking more in the lines of the case when you dont want the
> > default to change because something has changed.
> 
> Then don't make the default depend on something you're going to change.
> 
> Well, what this is really about is about closure vars changing when the  
> outer scope changes them instead of the value of the closure vars being  
> captured by the new lexical scope. This has been proposed before (to  
> change this behaviour on closure variables in general) and rejected.  
> (though I am in favour of it)
> Python is a late binding language in just about everything, and that is  
> considered to be a good thing. The point you're making is exactly the  
> early-vs-late binding discussion.
> 
> > I still think this would be optimizing towards the case where you
> > should put the code in the body. What if i want a static default
> > parameter, never to change, but i want to compute it at compile time?
> > Should i need to use extra syntax for that? Isnt this case more common
> > than the others? Something like:
> >
> > def foo( pixels = (640*480) ): pass
> >
> > Should overriding '*' change that default value? (can you do that in
> > python3k? i think you cant in 2.x)
> 
> I'm not really sure if you can either. Anyway, the only cases I can think  
> of when this makes sense is when there's a bug in '*' and you want to  
> patch it, or if you're overloading '*' to work with other values, without  
> changing the meaning for ints. In both of these cases it would be a good  
> resp. neutral thing to late-bind '*'

No.  You cannot change the meaning of any operation on built-in types.
You can subclass the built-in types and add your own implementation of a
__magic__ method, or you can prefix your other operations with some
other type that does something else (X*640*480), but you can't
monkey-patch int to have a new __mul__ operation.

In Python, the functions that get called when an operation is called on
an object defined in C are "bound early", that is, they cannot be
changed during runtime (unless you write some C code to monkey about
with Python internals - which is a *bad* idea). The functions that get
called when an operation is called on an object defined in Python may be
"bound early", as is the case with properties and other descriptors on
new-style classes, but classic classes, generally speaking, can be
manipulated at will (though you sometimes need to be careful when adding
or changing new instance, class, and static methods).


> Yup. But let's not fill the language with gotchas for the newbies to find  
> and learn from :)

No one is advocating for *adding* gotchas to the language; this thread
is more or less a question of whether this particular default argument
gotcha is worth changing the language.


> You'll get to like the new way :)

And you will get used to and like the old way.


 - Josiah