Josiah Carlson wrote:
> Steven Bethard <[EMAIL PROTECTED]> wrote:
>
>>I agree that an operator.methodcaller() shouldn't try to support
>>multiple methods. OTOH, the syntax
>>methodcall.method(*args, **kwargs)
>>doesn't really lend itself to multiple methods either.
>
>
> But that's OK, we d
[Steven Bethard]
> > I agree that an operator.methodcaller() shouldn't try to support
> > multiple methods. OTOH, the syntax
> > methodcall.method(*args, **kwargs)
> > doesn't really lend itself to multiple methods either.
[Josiah Carlson]
> But that's OK, we don't want to be calling multiple
Steven Bethard <[EMAIL PROTECTED]> wrote:
> I agree that an operator.methodcaller() shouldn't try to support
> multiple methods. OTOH, the syntax
> methodcall.method(*args, **kwargs)
> doesn't really lend itself to multiple methods either.
But that's OK, we don't want to be calling multiple
Martin v. Löwis wrote:
> Steven Bethard wrote:
> >>I thought that:
> >> operator.attrgetter() was for obj.attr
> >> operator.itemgetter() was for obj[integer_index]
> >
> >
> > My point exactly. If we're sticking to the same style, I would expect that
> > for
> > obj.method(*args, **kwargs)
Steven Bethard wrote:
>>I thought that:
>> operator.attrgetter() was for obj.attr
>> operator.itemgetter() was for obj[integer_index]
>
>
> My point exactly. If we're sticking to the same style, I would expect that
> for
> obj.method(*args, **kwargs)
> we would have something like:
>
Josiah Carlson wrote:
> Steven Bethard <[EMAIL PROTECTED]> wrote:
> > If we're going to move away from the itemgetter() and attrgetter()
> > style, then we should be consistent about it and provide a solution
> > (or solutions) that answers all of these problems:
> > obj.attr
> > obj.attr(*
Steven Bethard <[EMAIL PROTECTED]> wrote:
>
> Martin v. Löwis wrote:
> > So I would propose the syntax
> >
> > lst.sort(key=virtual.lower) # where virtual is functional.virtual
>
> Shane Hathaway wrote:
> > class virtual:
> > def __getattr__(self, name):
> > return lambda obj: g
On 8/18/05, Nick Coghlan <[EMAIL PROTECTED]> wrote:
> Brett Cannon wrote:
> > Oh, when should we think of putting reduce into functional? I
> > remember this was discussed when it was realized reduce was the only
> > functional built-in that is not covered by itertools or listcomps.
>
> I expect
Brett Cannon wrote:
>>>What I think you want is not a partial method, instead, you want to
>>>turn a method into a standard function, and in a 'virtual' way.
>>>
>>>So I would propose the syntax
>>>
>>> lst.sort(key=virtual.lower) # where virtual is functional.virtual
>>
>>I like this, but would h
Martin v. Löwis wrote:
> So I would propose the syntax
>
> lst.sort(key=virtual.lower) # where virtual is functional.virtual
Shane Hathaway wrote:
> class virtual:
> def __getattr__(self, name):
> return lambda obj: getattr(obj, name)()
> virtual = virtual()
I think (perhaps beca
Brett Cannon wrote:
>>>What I think you want is not a partial method, instead, you want to
>>>turn a method into a standard function, and in a 'virtual' way.
>>>
>>>So I would propose the syntax
>>>
>>> lst.sort(key=virtual.lower) # where virtual is functional.virtual
>>
>>I like this, but would h
[Guido]
> They feel related to attrgetter more than to partial.
That suggests operator.methodcall()
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options
On 8/18/05, Guido van Rossum <[EMAIL PROTECTED]> wrote:
> On 8/18/05, "Martin v. Löwis" <[EMAIL PROTECTED]> wrote:
> > As for the more general proposal: -1 on more places to pass strings to
> > denote method/function/class names. These are ugly to type.
>
> Agreed.
>
> > What I think you want is
On 8/18/05, "Martin v. Löwis" <[EMAIL PROTECTED]> wrote:
> As for the more general proposal: -1 on more places to pass strings to
> denote method/function/class names. These are ugly to type.
Agreed.
> What I think you want is not a partial method, instead, you want to
> turn a method into a stan
Martin v. Löwis wrote:
> So I would propose the syntax
>
> lst.sort(key=virtual.lower) # where virtual is functional.virtual
Ooh, may I say that idea is interesting! It's easy to implement, too:
class virtual:
def __getattr__(self, name):
return lambda obj: getattr(obj, name)()
Ian Bicking wrote:
>
> lst = ['A', 'b', 'C']
> lst.sort(key=partialmethod('lower'))
>
> Which sorts by lower-case. Of course you can use str.lower, except
> you'll have unnecessarily enforced a type (and excluded Unicode). So
> you are left with lambda x: x.lower().
For this specif
Raymond Hettinger wrote:
instance:
lst = ['A', 'b', 'C']
lst.sort(key=partialmethod('lower'))
>>>
>>>We've already got one:
>>>
>>> lst.sort(key=operator.attrgetter('lower'))
>>
>>Doesn't that just sort on the str.lower or unicode.lower method
>> object?
>
> My mis
> > [Ian Bicking]
> > > I think partial() misses an important use case of method getting,
for
> > > instance:
> > >
> > > lst = ['A', 'b', 'C']
> > > lst.sort(key=partialmethod('lower'))
> >
> > We've already got one:
> >
> >lst.sort(key=operator.attrgetter('lower'))
>
> Doesn't
Raymond Hettinger wrote:
> [Ian Bicking]
> > I think partial() misses an important use case of method getting, for
> > instance:
> >
> > lst = ['A', 'b', 'C']
> > lst.sort(key=partialmethod('lower'))
>
> We've already got one:
>
>lst.sort(key=operator.attrgetter('lower'))
Doesn't
[Ian Bicking]
> I think partial() misses an important use case of method getting, for
> instance:
>
> lst = ['A', 'b', 'C']
> lst.sort(key=partialmethod('lower'))
We've already got one:
lst.sort(key=operator.attrgetter('lower'))
Raymond
___
> Nick Coghlan writes:
> > I'm actually half-tempted to suggest that [map, filter and reduce]
> should be
> > aliased in the functional module for 2.5 (in addition to being in
> builtins -
> ala
> > the contents of the exceptions module).
>
> Well, I think it's a good idea, so I'll formally propos
Nick Coghlan writes:
> I'm actually half-tempted to suggest that [map, filter and reduce] should be
> aliased in the functional module for 2.5 (in addition to being in builtins -
ala
> the contents of the exceptions module).
Well, I think it's a good idea, so I'll formally propose it! Let's alias
Steven Bethard wrote:
(I'm also secretly hoping that map, filter,
reduce, etc. will be moved to the functional module in the future,
maybe in Python 3.0. But that's probably just my love for list
comprehensions and generator expressions speaking.) ;-)
Given Guido's stated desire to get rid of thos
[Peter Harris]
> I look forward to the day when I can just use it.
You PEP is marked as final. The code has been checked in to CVS and
will be in Py2.5.
Congrats,
Raymond Hettinger
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.pyt
Peter Harris <[EMAIL PROTECTED]> wrote:
> However, I sympathise with anyone who feels unhappy about a new module
> just for what amounts to one function.
Well, since it seems that the emphasis in Python development is now
moving more towards expanding the standard library, a module that has
only o
Overall, I have no major objections to the PEP or the patch. Before it
goes in on auto-pilot, it would be darned nice if the proponents said
that they've found it helpful in real code and that they are satisfied
with the timings.
I guess "darned nice" is the best you can hope for. Not sure i
Samuele Pedroni wrote:
Nick Coghlan wrote:
The initial suggestion was to provide a __get__ method on partial
objects, which forces the insertion of the reference to self at the
beginning of the argument list instead of at the end:
def __get__(self, obj, type=None):
if obj is None:
[Martin]
> It seems to me that the patch will be committed shortly, assuming
> somebody corrects the remaining flaws in the implementation. I could
> do that, but I would prefer if somebody contributed an updated patch.
Done.
Raymond
___
Python-Dev ma
Raymond Hettinger wrote:
My reading of the PEP did not include making the structure members
public. This complicates and slows the implementation. The notion of
introducing mutable state to the PFA is at odds with the driving forces
behind functional programming (i.e. statelessness).
Notice that
Paul Moore wrote:
While I'm not saying that it's too late to attempt to persuade Guido
to reverse himself, it does seem to me to be a lot of fuss over a
fairly small function - and no-one said anything like this at the
time.
I would probably fuss much less if it would not simultaneously introduce
a
Nick Coghlan wrote:
The initial suggestion was to provide a __get__ method on partial
objects, which forces the insertion of the reference to self at the
beginning of the argument list instead of at the end:
def __get__(self, obj, type=None):
if obj is None:
return self
> > Along the way, they should assess whether
> > it is as applicable as expected, whether the existing limitations
are
> > problematic, and whether performance is an issue.
>
> Ah, so you question the specification, not the implementation of it.
My only issue with the PEP is that it seemed much
On Sun, 27 Feb 2005 19:05:18 +0100, "Martin v. Löwis"
<[EMAIL PROTECTED]> wrote:
> Again, this I cannot understand. I do believe that there is no better
> way to implement the PEP. The PEP very explicitly defines what precisely
> functional.partial is, and the implementation follows that specificat
Raymond Hettinger wrote:
I would like for the principal advocates to reach a consensus that the
proposed implementation is a winner.
That I cannot understand. Do you want the advocates to verify that the
implementation conforms to the specification? or that the implementation
of the PEP is faster t
> > Are you sure about that? Contriving examples is easy, but download
a
> > few modules, scan them for use cases, and you may find, as I did,
that
> > partial() rarely applies. The argument order tends to be
problematic.
>
> So would you like to see the decision to accept PEP 309 reverted?
I w
On Sun, 27 Feb 2005 09:31:26 +0100, "Martin v. Löwis"
<[EMAIL PROTECTED]> wrote:
> Raymond Hettinger wrote:
> > Are you sure about that? Contriving examples is easy, but download a
> > few modules, scan them for use cases, and you may find, as I did, that
> > partial() rarely applies. The argumen
Raymond Hettinger wrote:
Are you sure about that? Contriving examples is easy, but download a
few modules, scan them for use cases, and you may find, as I did, that
partial() rarely applies. The argument order tends to be problematic.
So would you like to see the decision to accept PEP 309 revert
Dima Dorfman wrote:
Nick Coghlan <[EMAIL PROTECTED]> wrote:
Here, b is specialized at cut time, a is passed through the slot, and
c is passed through the implicit slots at the end. The only thing this
can't do is a generic right-"curry"--where we don't know how many
parameters come before the one w
Nick Coghlan <[EMAIL PROTECTED]> wrote:
> Raymond Hettinger wrote:
> >* The instance method limitation never came up for me. However, it
> >bites to have a tool working in a way that doesn't match your mental
> >model. We have to document the limitations, keep them in mind while
> >programming, a
Raymond Hettinger wrote:
* The PFA implementation proposed for Py2.4 ran slower than an
equivalent closure. If the latest implementation offers better
performance, then that may be a reason for having it around.
Not having done the timing, I'll defer to Paul and yourself here. However, one
of the
On Sat, 26 Feb 2005 19:26:11 -0500, Raymond Hettinger <[EMAIL PROTECTED]> wrote:
> Are you sure about that? Contriving examples is easy, but download a
> few modules, scan them for use cases, and you may find, as I did, that
> partial() rarely applies. The argument order tends to be problematic.
> I did a quick experiment:
>
> >python -m timeit -s "from operator import itemgetter; l=range(8)"
> "itemgetter(1)(l)"
> 100 loops, best of 3: 0.548 usec per loop
>
> >python -m timeit -s "l=range(8)" "(lambda x:x[1])(l)"
> 100 loops, best of 3: 0.597 usec per loop
>
> That's far less o
> But this all reminds me of the discussion
> over itemgetter/attrgetter. They also special-case particular uses of
> lambda, and in those cases the stated benefits were speed and
> (arguably) readability (I still dislike the names, personally).
I wouldn't use those as justification for partial().
On Sat, 26 Feb 2005 13:20:46 -0500, Raymond Hettinger
<[EMAIL PROTECTED]> wrote:
> It is better to teach how to write a closure than to introduce a new
> construct that has its own problems and doesn't provide a real
> improvement over what we have now.
You make some good points. But this all remi
Paul Moore wrote:
Personally, I'd rather see partial as it stands, with its current
limitations, included. The alternative seems to be a potentially long
discussion, petering out without conclusion, and the whole thing
missing Python 2.5. (I know that's a long way off, but this already
happened wi
On Sat, 26 Feb 2005 16:50:06 +1000, Nick Coghlan <[EMAIL PROTECTED]> wrote:
> Moving a discussion from the PEP309 SF tracker (Patch #941881) to here, since
> it's gone beyond the initial PEP 309 concept (and the SF tracker is a lousy
> place to have a design discussion, anyway).
>
> The discussion
46 matches
Mail list logo
