invoking multiple methods (Was: Python vs. Ruby)
mwm at mired.org
Fri Jan 10 16:38:27 CET 2003
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?
> 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 mired.org> http://www.mired.org/home/mwm/
Independent WWW/Perforce/FreeBSD/Unix consultant, email for more information.
More information about the Python-list