Re: [Python-Dev] PEP 309: Partial method application
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)
we would have something like:
operator.methodcaller('method', *args, **kwargs)
You might be missing one aspect of attrgetter, though. I can have
f = operator.attrgetter('name', 'age')
and then f(person) gives me (person.name, person.age). Likewise for
itemgetter(1,2,3).
[snip]
I don't know what the common use for
attrgetter is: one or more attributes?
Well, in current Python code, I'd be willing to wager that it's one,
no more, since Python 2.4 only supports a single argument to
itemgetter and attrgetter. Of course, when Python 2.5 comes out, it's
certainly possible that the multi-argument forms will become
commonplace.
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.
STeVe
--
You can wordify anything if you just verb it.
--- Bucky Katt, Get Fuzzy
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 309: Partial method application
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 methods anyways, do we? I'd personally like to see an example it makes sense if someone says that we do. - Josiah ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 309: Partial method application
[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 methods anyways, do we? I'd personally like to see an example it makes sense if someone says that we do. If an obvious syntax doesn't emerge, don't fret. The most obvious approach is to define a regular Python function and supply that function to the key= argument for list.sort() or sorted(). A virtue of the key= argument was reducing O(n log n) calls to just O(n). Further speed-ups are a false economy. So there's no need to twist syntax into knots just to get a C based method calling function. Likewise with map(), if a new function doesn't fit neatly, take that as a cue to be writing a plain for-loop. Raymond ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 309: Partial method application
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 don't want to be calling multiple methods anyways, do we? I'd personally like to see an example it makes sense if someone says that we do. Several people argued that the version with a string method name should be added for consistency. I only pointed out that doing so would not be completely consistent. Regards, Martin ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Deprecating builtin id (and moving it to sys())
On 8/18/05, Guido van Rossum [EMAIL PROTECTED] wrote: On 8/17/05, Anthony Baxter [EMAIL PROTECTED] wrote: If you _really_ want to call a local variable 'id' you can (but shouldn't). Disagreed. The built-in namespace is searched last for a reason -- the design is such that if you don't care for a particular built-in you don't need to know about it. In practice, it causes much confusion if you ever use a local variable that has the same name as the built-in namespace. If you intend to use id as a variable, it leads to confusing messages when a typo or editing error accidentally removes the definition, because the name will still be defined for you. It also leads to confusion when you later want to use the builtin in the same module or function (or in the debugger). If Python defines the name, I don't want to provide a redefinition. Jeremy ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Deprecating builtin id (and moving it to sys())
On 8/19/05, Jeremy Hylton [EMAIL PROTECTED] wrote: On 8/18/05, Guido van Rossum [EMAIL PROTECTED] wrote: On 8/17/05, Anthony Baxter [EMAIL PROTECTED] wrote: If you _really_ want to call a local variable 'id' you can (but shouldn't). Disagreed. The built-in namespace is searched last for a reason -- the design is such that if you don't care for a particular built-in you don't need to know about it. In practice, it causes much confusion if you ever use a local variable that has the same name as the built-in namespace. If you intend to use id as a variable, it leads to confusing messages when a typo or editing error accidentally removes the definition, because the name will still be defined for you. It also leads to confusion when you later want to use the builtin in the same module or function (or in the debugger). If Python defines the name, I don't want to provide a redefinition. This has startled me a few times, but never for more than 30 seconds. In correct code there sure isn't any confusion. -- --Guido van Rossum (home page: http://www.python.org/~guido/) ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
