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
___
20 matches
Mail list logo
