[Python-ideas] return value of yield expressions

Nick Coghlan ncoghlan at gmail.com
Wed Sep 14 09:30:00 CEST 2011


On Wed, Sep 14, 2011 at 3:01 PM, Ron Adam <ron3200 at gmail.com> wrote:
> On Wed, 2011-09-14 at 13:41 +1000, Nick Coghlan wrote:
>> On Wed, Sep 14, 2011 at 3:23 AM, Ron Adam <ron3200 at gmail.com> wrote:
>> > If we could get the functions arguments when a function is done instead
>> > of getting the return value.  (The modified function arguments object is
>> > the return value in this case.)
>> >
>> >      fargs = &foo(a, b, c, d=4)
>>
>> This use case is covered by the bind() method in PEP 362 [1]:
>>
>>     foo_signature = inspect.signature(foo)
>>     fargs = foo_signature.bind(a, b, c, d=4)
>>
>> [1] http://www.python.org/dev/peps/pep-0362/#signature-object
>
> It doesn't quite do the same thing, and it's not nearly as easy to use.

And magic syntax is better? This is an incredibly niche use case, so
there is zero justification for giving it special syntax when
functions, methods and classes will do the job just fine (it's also
worth keeping in mind that Guido hasn't even officially given PEP 362
itself the nod at this point).

> Regarding PEP 362:
>
> The signature function gets the signature object from the target
> function, ok,  The  use case in the pep describes binding and
> introspecting the signature object for various purposes, which is a nice
> thing to be able to do.   But after that, it just calls the functions
> with the same *args and **kwds that was used to bind the signature.   So
> it's unpacking args and kwds a second time.
>
> Will there be a way to reuse the bound signature object with a function
> directly without unpacking it?

No such micro-optimisation is planned (it would require a complete
redesign of the way arguments are passed to functions). If the
performance hit of explicit validation is unacceptable, just don't
bother with it and accept that you won't get an error until the
function is actually used.

Cheers,
Nick.

-- 
Nick Coghlan   |   ncoghlan at gmail.com   |   Brisbane, Australia



More information about the Python-ideas mailing list