RetroSearch Browse

Fri Oct 17 16:40:28 EDT 2003 · https://mail.python.org/pipermail/python-dev/2003-October/038900.html

On Friday 17 October 2003 07:53 pm, Phillip J. Eby wrote:
> At 06:52 PM 10/17/03 +0200, Alex Martelli wrote:
> >On Friday 17 October 2003 06:03 pm, Phillip J. Eby wrote:
> > > Yes, what you propose is certainly *possible*.  But again, if you
> > > really needed an iterator as an index, you can right now do:
> > >
> > > sum[ [x*x for x in blaap] ]
> >
> >Actually, I need to use parentheses on the outside and brackets only
> >on the inside -- I assume that's what you meant, of course.
>
> No, I meant what I said, which was that if you "really needed an iterator
> as an *index*" (emphasis added).  I suppose I technically should have said,
> if you really want to provide an *iterable*, since a list is not an
> iterator.  But I figured you'd know what I meant.  :)

Ah, no, I didn't get your meaning.  But yes, you could of course
pass iter([ x*x for x in blaap ]) as an iterator (not just iterable) index
to whatever... as long as blaap was a FINITE iterator, of course.  If
you can't count on blaap being finite, you'd need to code and name
a separate generator such as:

def squares(blaap):
    for x in blaap:
       yield x*x

then pass the result of calling squares(blaap), or you could choose
to use itertools.imap and a lambda, etc etc.

> >I agree it's clearer -- a tad less flexible, as you don't get to do
> > separately selector = Top(10)
> >and then somewhere else
> >     selector[...]
> >but "oh well", and anyway the issue would be overcome if we had currying
> >(we could be said to have it, but -- I assume you'd consider
> >     selector = Top.__get__(10)
> >some kind of abuse, and besides, this 'currying' isn't very general).
>
> Hmmm...  that's a hideously sick hack to perform currying...  but I *like*
> it.  :) Not to use inline, of course, I'd wrap it in a 'curry'
> function.  But what a lovely way to *implement* it, under the hood.  Of
> course, I'd actually use 'new.instancemethod', since it would do the same

Yes, def curry(func, arg): return new.instancemethod(func, arg, object)
IS indeed way more general than func.__get__(arg) [notably, you get to
call it repeatedly to curry more than one argument, from the left].  But
if you have to define a curry function anyway, it's not a huge win vs

def curry(func, arg):
    def curried(*args): return func(arg, *args)
    return curried

or indeed more general variations thereof such as

def curry(func, *curried_args):
    def curried(*args): return func(*(curried_args+args))
    return curried

Alex

Home - News ( United States | United Kingdom | Italy | Germany ) - Football scores

Showing content from https://mail.python.org/pipermail/python-dev/2003-October/038900.html below:

[Python-Dev] accumulator display syntax