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

[CTO]

> 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.

> but have a fresh [] bound to x. You're supporting the syntax:
>
> @call_lambdas  # Geremy Condra uses the name 'runtime'
> def f(x=lambda:[]):
>     ...
>

For the record, I'm not supporting a syntax. I'm simply
stating that this can be done in Python as it currently
stands, and that I am most emphatically not in favor
of making function signatures any more complex than
they already are.

> (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.

> If I were to use the proposed late-binding feature, I would want it to
> be easy to use and obvious. I don't mind having to learn special
> syntax -- I'm not asking for it to be intuitive or guessable. But
> having to define the default value as a function (with or without
> lambda!) *and* call a decorator doesn't seem either easy or obvious. It
> feels like a kludge designed to get around a limitation of the
> language. (If you don't like the negative connotations of 'kludge',
> read it as 'hack' instead.) In other words, it looks like your
> suggestion is "let's find another idiom for late-binding default
> arguments" rather than "let's give Python built-in support for optional
> late-binding of default arguments".

My suggestion is neither to find another idiom or to build in
late-binding support. Some people- yourself included- 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.

> If the first one is your intention, then I'll just walk away from this
> discussion. I already have a perfectly obvious and explicit idiom for
> late-binding of default arguments. I don't need a second one,
> especially one which I find exceedingly inelegant and ugly. If you want
> to use that in your own code, go right ahead, but I hope it never makes
> it into any code I ever need to read. -1 from me on any solution which
> requires both a decorator and special treatment of defaults in the
> parameter list.

If you are satisfied with the existing idiom, then use it. If you're
not,
my code is out there. If you don't like that, then write your own.

> In my opinion, only a solution with built-in support from the compiler
> is worth supporting.

I'm afraid I'm unconvinced on that point.

> Anything else is a heavyweight, complicated
> solution for a problem that already has a lightweight, simple solution:
> use a sentinel. We already have a concise, fast, straightforward idiom
> which is easily learned and easily written, and while it's not
> intuitively obvious to newbies, neither is the suggested
> decorator+lambda solution. We don't need a complicated, verbose,
> hard-to-explain, hard-to-implement solution as well.
>
> --
> Steven D'Aprano

I think I've already addressed this point, but once more for
the record, I'm just not convinced that any of this- my code
or your proposed changes- are needed. Until then you can have
my -1.

Geremy Condra