[Python-ideas] Default arguments in Python - the return - running out of ideas but...

[Steven D'Aprano]

On Fri, 15 May 2009 12:37:19 pm CTO wrote:
> > Some people don't like writing:
> >
> > def f(x=SENTINEL):
> >     if x is SENTINEL: x = []
> >
> > and wish to have syntax so they can write something approaching:
> >
> > def f(x=[]):
> >     ...
>
> And I understand that. However, I don't think it's important
> enough to make it worth changing the language, adding to
> Python's already significant function call overhead, or
> making the job of parsing function signatures more difficult.
> If there is a mechanism to do this inside of Python- and
> there are several- it is my personal opinion that those
> should be used in preference to modifying the language. As
> I am neither the smartest nor most competent programmer
> here, feel free to disregard my opinion- but the code I
> have produced matches one of the proposed syntaxes very
> closely, even if it is not the one you prefer.

Your code also "add[s] to Python's already significant function call 
overhead" as well as "making the job of parsing function signatures 
more difficult".

I don't mean to dump on your code. What you are trying to do is 
obviously very difficult from pure Python code, and the solutions you 
have come up with are neat kludges. But a kludge is still a kludge, no 
matter how neat it is :)

[...]
> > (For the record, I've suggested creating a unary-& operator so that
> > we can write "def f(&x=[])" to get late-binding of x.)
>
> It's simple, short, and concise. If I were to get behind
> a proposal to change the language to support this feature,
> I would probably either get behind this one or perhaps
> a more general system for adding a metaclass equivalent
> to functions. However, as things stand I remain unconvinced
> that any of these things are necessary, or even
> particularly desirable, given the aforementioned
> complexity of function signatures.

I think we two at least agree. I don't think there's anything wrong with 
the current sentinel idiom. It's not entirely intuitive to newbies, or 
those who don't fully understand Python's object-binding model, but I 
don't consider that a flaw. So I don't see the compile-time binding of 
default args to be a problem that needs solving.

But other people do, and they are loud and consistent in their 
complaints. Given that the squeaky wheel (sometimes) gets the grease, 
I'd just like to see a nice solution to a (non-)problem rather than an 
ugly solution.

So I'm +0 on my proposal -- I don't think it solves a problem that needs 
solving, but other people do. I'm -1 on decorator+lambda solutions, 
because not only do they not solve a problem that needs solving, but 
they don't solve it in a particularly ugly and inefficient way *wink*


> My suggestion is neither to find another idiom or to build in
> late-binding support. Some people- yourself included- 

I think you've misunderstood my position. I'm one of the people 
defending the current semantics of default arg binding. But since 
others want optional late binding, I'm just trying to find a syntax 
that doesn't bite :)


> want a 
> new syntax. I demonstrated that close approximations of some
> of the mentioned syntaxes were possible in the language already,
> and while I appreciate that your preferred syntax is not on that
> list, I remain unconvinced that its purported benefits outweigh
> what I perceive to be its drawbacks.

Just out of curiosity, what do you see as the drawbacks? The ones that 
come to my mind are:

* people who want late binding to be standard will be disappointed
(but that will be true of any solution)

* requires changes to Python's parser, to allow unary-&
(but that will probably be very simple)

* requires charges to Python's compiler, to allow for some sort of 
late-binding semantics (thunks?)
(but that will probably be very hard)

* requires people to learn one more feature 
(so newbies will still be confused that def f(x=[]) doesn't behave as 
they expect).



-- 
Steven D'Aprano