invoking multiple methods (Was: Python vs. Ruby)
bokr at oz.net
Fri Jan 10 19:01:46 CET 2003
On Fri, 10 Jan 2003 15:38:27 GMT, Mike Meyer <mwm at mired.org> wrote:
>bokr at oz.net (Bengt Richter) writes:
>> On Thu, 09 Jan 2003 15:57:38 GMT, Mike Meyer <mwm at mired.org> wrote:
>> >Erik Max Francis <max at alcyone.com> writes:
>> >> "Stuart D. Gathman" wrote:
>> >> > aList.sort();.reverse() # aList.sort(); aList.reverse()
>> >> > A statement cannot begin with '.', so ';.' means to invoke another
>> >> > method
>> >> > on the same object.
>> >> But is this awkwardness really worth it? One of Python's truly great
>> >> assets is its transparently readable code. I'm opposed on general
>> >> principle to anything which defeats that.
>> >True. However, the idea of specifying multiple methods on the same
>> >object is consistent with recent changes (op=, for instance), and
>> >seems useful enough to be worth writing a PEP for - *if* a readable
>> >syntax can be invented for it.
>> >I don't like ;.. I'm not sure I like the idea of tweaking the
>> >semantics of statement at all. Maybe something like:
>> > aList.(sort(), reverse())
>> >Almost like using a tuple as the method, and it does all the
>> >invocations in the tuple. Except it isn't a real tuple, because the
>> >methods aren't reall calls.
>> I'd rather reserve the xxx.(something) syntax for an alternate spelling
>> of getattr(xxx, something), where something is an expression resulting in a string.
>I think the multiple call shorthand is better than the getattr
>shorthand. If I only get one, I want multiple calls. Or is there
>already a PEP for the getattr shorthand?
Not that I know of. It just seemed natural ;-)
But your idea is growing on me. If you take the sequence to be args of a kind
of repeating text macro, where obj.(xxx,yyy,zzz) => obj.xxx; obj.yyy; obj.zzz
you would have a kind of "with" e.g.,
Don't take too seriously ;-)
>> How about getting your parens without a dot, using __call__ and passing bound methods?
>The whole point is to avoid having to list the bound object multiple
>times, so no, that doesn't buy you anything.
You didn't comment on the alternative of passing _unbound_ methods
(or concise aliases, which I thought looked pretty clean) ;-)
"and you can do it now"(TM) ;-)
More information about the Python-list