[Python-ideas] return value of yield expressions

Guido van Rossum guido at python.org
Fri Sep 16 16:40:03 CEST 2011


On Thu, Sep 15, 2011 at 9:26 PM, Ron Adam <ron3200 at gmail.com> wrote:
> On Wed, 2011-09-14 at 17:30 +1000, Nick Coghlan wrote:
>> 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)
>
> I don't know about it being a niche use case.   How many time is (*args,
> **kwds) used to pass the signature data forward or back?
>
> I think this might be a lateral issue that could compliment Pep 362.
>
>
> Thinking about it, I am able (with a bit of work) get the final
> signature data mapping from within a function and return it.
>
> def xupdate_map(map1, map2):
>    """ Only update values in map1 from map2. """
>    for k in map1.keys():
>        map1[k] = map2[k]
>
>
> def foo(v, count=2):
>    sig_vals = locals()
>
>    # Do stuff that may change v and/or count.
>    for n = range(count):
>        v += 1
>
>    return xupdate_map(sig_vals, locals())
>
>
> That's pretty limiting and I can't call foo again with the result.  It's
> also not very efficient either.
>
>
> I need to play with this a bit more before I can really explain what I
> seem to be thinking of.  If I get it pinned down with some real world
> examples of how it would help, then maybe I'll post it here later.
>
> The general idea is to be able to use the signature mapping "such as
> what bind returns" in a more direct way with more freedom than *args,
> and **kwds allows.

I think you're on the wrong path. Structured data ought to be
represented as a class instance, or some other suitable data
structure, not as an argument list to a function. Otherwise before you
know it you will have reinvented namedtuple. I feel pretty strongly
that adding syntax so that you can unpack an expression the way
function arguments are unpacked is a bad way to evolve Python.

-- 
--Guido van Rossum (python.org/~guido)



More information about the Python-ideas mailing list