"Jan Kanis" <jan.kanis@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@gmail.com> wrote:
On 1/31/07, Jan Kanis <jan.kanis@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