[Python-ideas] parameter omit

Jim Jewett jimjjewett at gmail.com
Fri May 11 17:00:18 CEST 2007


On 5/11/07, Aaron Brady <castironpi at comcast.net> wrote:

> carefully: Have you asserted that defaults are -always- available and
> published, in the standard library as well as elsewhere?

Of course not.

Sometimes the real default value doesn't really exist yet, because it
is constructed after the function gets called with 'None'.  Your
proposal doesn't change this.

When the default should be introspectable and isn't, this is usually
because the function was written in C, and the author wasn't careful
to add the proper docstring tagging.  If they aren't supporting
docstrings yet, they won't bother to support your new object either --
so it has to be done either at the interpreter level or with a wrapper
function.

The costs in the interpreter would be significant, both in complexity
(a special case) and in speed (that particular loop is tight enough
that any change can have unexpected results by changing cache
performance).

The wrapper solution seems good enough to me; it doesn't slow things
down unless you use it.  You can even automate it with monkey-patching
if you like.

> Within a full 24 hours, I expect an, "I like this, may be good.  Here's my
> personal e-mail address, get back to me in a week if you haven't heard
> anything."

I am pleasantly surprised to get 24 hour response from a vendor, even
when I (or, rather, my employer) has paid for that support.

But in this case, you actually did get a fairly quick response; it
just wasn't what you wanted, because the responders did *not* think it
was likely to be a good idea, and you weren't willing to listen to the
alternative solutions they proposed.

> Could one extra value in __builtins__ already be worth all our third-parties'
> time who could relax and get along?

If you compile your own local copy, then sure.  If you want it in the
worldwide distribution, then probably not; backwards compatibility
means that it will change only at a bureaucratic pace.

As a point of comparison, your proposal would actually be a larger
change than decorators, for a less frequent use case.

Decorators were agreed to in theory for 2.3 (around 2002/2003), but
concerns about how to do it right kept them out until 2.4.  Class
decorators were still not included (despite a working implementation
which was actually a bit simpler) because there was a chance they
wouldn't be needed, and adding things is easier than taking them back
out.  Class decorators have now been approved for Python 2.6, which
will probably be available some time next year.

-jJ



More information about the Python-ideas mailing list