Not to mention for the wonderful incompatibility with everyone else in
the world <0.9 grin> ...
> What it also means is that even if list methods DID return something
> besides None I would never have noticed, but their utility would
> definitely increase (for me and my ilk, that is).
I still don't believe you, but it _should_ be very easy to set me
straight (see below).
> Here's a question: do non-None return values still get printed out if
> you are not running Python interactively?
Yup. I personally don't use this feature(?) in non-interactive mode, but
some people certainly do.
> | > ...
> | > It would be more useful if [list methods] returned the listobject that
> | > resulted from the method call. That way I could chain operations
> | > together like so:
> | >
> | > mylist = [1, 2, 3].reverse().append(0).reverse()
> | >
> | > and mylist would == [0, 1, 2, 3].
> |
> | Prediction: You'll lose interest in this after you get more Python
> | coding under your belt. Why? Because it's rarely useful. E.g., if you
> | really want to add something to the start of a list (as you're doing in
> | your example), it's better in every respect to just say
> |
> | list.insert(0, something)
>
> Another thing I should have mentioned is that I've been coding
> Python for a year and a half now and I use the afore-mentioned
> chaining of statements every day!
It's not my claim that method-chaining in general isn't useful. My claim
is that method-chaining is almost useless for _most builtin types_
specifically, including the list type.
I understood that your example was off the cuff. What I didn't and don't
understand is _why_ you make the claim that "their utility would
definitely increase" if you could chain list methods. That is, I'm
looking for a _real_ example that supports your claim. Or, in other
words, I think there are deeper reasons than "off the cuff" for why the
example you gave was silly (an elaborate way to do something that's much
more easily done a different way). If you had a truly useful example in
mind, I suspect you would have given it (if not before, then now <wink>).
My "prediction" wasn't meant as an attack, it was predicting that you'd
follow the same path I did: at first, I too was bothered that methods for
built-in types didn't chain, but after a couple years of this the _only_
actual example I found irritating was the inability to say
list.sort().reverse()
But I got over that long ago -- it's such a tiny nit that "their utility
would definitely increase" does seem strongly overstated to me. But
perhaps you have better real uses in mind -- if so, let's see 'em!
> [sez he writes his classes so that all methods that can, do return self]
Many people do that, and no argument from me about it.
> ... That way I can say things like:
>
> obj.scale(2).moveBy(1,0,0).setColor('green')
>
> It makes for more compact, and if you ask me, more readable code.
I agree!
> Providing the ability to do this with listobjects (and hopefully some
> day stringobjects!) methods will simply provide the same benefits.
But not with that. The only example on your table remains
list.reverse().append(0).reverse(), which is neither compact nor readable
compared to the alternative list.insert(0,0). The list methods that
(logically) _could_ be chained aren't nicely orthogonal like your
"scale", "moveBy" (etc) methods, so the notion that chaining them would
be a real win is not at all obvious.
> And speaking of automatic-return-value-output: why is there
> no flag to the interpreter to suppress this output?
Because the Virginia Cabal is the only terrorist group that's upset by
this <grin>.
> If I remember right there is one that supposedly does this, but it's
> never checked for in the code!
I believe Steve's right, that -k is the only relevant flag, and that
doesn't suppress but warns.
can't-wait-for-you-guys-to-release-python++<wink>-ly y'rs - tim
Tim Peters tim@ksr.com
not speaking for Kendall Square Research Corp