invoking multiple methods (Was: Python vs. Ruby)

Mike Meyer mwm at
Fri Jan 10 16:38:27 CET 2003

bokr at (Bengt Richter) writes:

> On Thu, 09 Jan 2003 15:57:38 GMT, Mike Meyer <mwm at> wrote:
> >Erik Max Francis <max at> 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?

> 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.

Mike Meyer <mwm at>
Independent WWW/Perforce/FreeBSD/Unix consultant, email for more information.

More information about the Python-list mailing list