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

[CTO]

On May 15, 4:14 am, Steven D'Aprano <st... at pearwood.info> wrote:
> On Fri, 15 May 2009 02:48:53 pm CTO wrote:
>
> > [super-snip]
>
> > > Just out of curiosity, what do you see as the drawbacks?
>
> > [snip]
>
> > 1) It adds to the complexity (and therefore overhead) of
> >    calling functions- not just the functions which use it,
> >    but even functions which operate as normal.
>
> Without an implementation, how can you possibly predict the cost of it?


>
> >    Python
> >    already has a hefty penalty for calling functions,
>
> I think you're badly mistaken. Python has a hefty cost for looking up
> names, but the overhead to *call* a function once you have looked up
> the name is minimal.
>
> >>> from timeit import Timer
> >>> def f():
>
> ...     pass
> ...>>> min(Timer('f', 'from __main__ import f').repeat())
> 0.32181000709533691
> >>> min(Timer('f()', 'from __main__ import f').repeat())
>
> 0.35797882080078125
>
> No significant difference between looking up f and looking up f and
> calling it.
>
> Even if you give the function a complex signature, it's still relatively
> lightweight:
>
> >>> def g(a=1, b=2, c=3, d=4, e=5, f=6, g=7, h=8, *args, **kwargs):
>
> ...     pass
> ...>>> min(Timer('g()', 'from __main__ import g').repeat())
>
> 0.55176901817321777
>
> >    and
> >    I really don't want it to get any heavier. My 'solutions',
> >    as incomplete as they are, at least don't slow down
> >    anything else.
>
> Oh the irony. Decorators are very heavyweight. Here's a decorator that
> essentially does nothing at all, and it triples the cost of calling the
> function:
>
> >>> from functools import wraps
> >>> def decorator(f):
>
> ...     @wraps(f)
> ...     def inner(*args, **kwargs):
> ...             return f(*args, **kwargs)
> ...     return inner
> ...>>> @decorator
>
> ... def h():
> ...     pass
> ...>>> min(Timer('h()', 'from __main__ import h').repeat())
>
> 1.1645870208740234
>
> I think, before making claims as to what's costly and what isn't, you
> should actually do some timing measurements.
>
> > 2) It adds to the complexity of introspecting functions.
> >    Take a good look at inspect.getfullargspec- its a
> >    nightmare, and either it gets worse under this (bad)
> >    or it doesn't include information that is available
> >    to the compiler (even worse).
>
> Well obviously this is going to make getfullargspec more complicated.
> But tell me, what do you think your solution using decorators does to
> getfullargspec?
>
> > In addition to those minuses, it doesn't actually add
> > to the capabilities of the language.
>
> It's an incremental improvement. Currently, late-binding of defaults
> requires boilerplate code. This will eliminate that boilerplate code.
>
> > If this were a
> > proposal to add early action to Python (the equivalent
> > of metaclasses or, to some extent, macro replacement)
> > I would be much more likely to support it, despite the
> > heavier syntax.
>
> > So, the existing idiom works pretty well,
>
> 100% agreed!
>
> > there doesn't seem to be a very good substitute,
>
> Not without support in the compiler.
>
> > it slows the whole language down to implement,
>
> You can't know that.
>
> > and it doesn't add any power if you do.
>
> It reduces boilerplate, which is a good thing. Probably the *only* good
> thing, but still a good thing.
>
> --
> Steven D'Aprano
> _______________________________________________
> Python-ideas mailing list
> Python-id... at python.orghttp://mail.python.org/mailman/listinfo/python-ideas