Na, I don't. I do assume that, in a discussion of Python, the usual
rules of the language, as it exsits today, and in the version Guido
distributes, apply -- except where someone has explicitly said they
don't. The original poster's examples seemed to imply he wanted these
methods to return the object. Perhaps I misunderstood him.
BTW, I certainly agree that "stringobjects don't have methods because
they're immutable" is no _explanation_. It was just an observation about
the way Python actually is (i.e., builtin immutable objects in Python
today simply do not support methods -- that's just a fact).
> [excited <wink> examples showing that methods can in fact return
> anything]
Sure; no argument.
> Ahhh... Now you give the real reason for sort() to have its odd return
> value.
It's "a reason" for not changing the behavior now. "The reason" Guido
did it this way to begin with remains unknown.
> It returns None *because* a mistake was made early on,
Which mistake was that <0.9 grin>? E.g., are you referring to Python
printing non-None expressions? Many who use Python interactively are
likely to disagree that _that's_ "a mistake".
> and compatibility with existing code requires this oddity.
Ah! Universal harmony restored <smile>.
> ...
> You do note that another slight problem with Python here however, in
> that every evaluation that is not "used" ... printed.
I've never felt this to be "a problem", but understand that you do.
> ...
> Haven't we all faced the problem you mention, wherein the return result
> from a function call must be "dealt with," in order to prevent it from
> printing?
In fact, the only time it's ever bothered me is when doing
os.system(cmd_string)
because the call returns the cmd's exit code, which then gets printed.
But there are so many easy ways to worm around that that it would take
all day to write them up <wink>.
I think what's happening here is that we have different _styles_ of
programming, and Python's current behavior doesn't get in the way of mine
but does get in the way of yours. E.g., in my programming I still follow
the old distinction between functions (which do return values) and
procedures (which do not -- or in the Python context return None), and
simply don't use one kind where the other kind was wanted. Python's
behavior matches that style well.
> *THIS* is the problem that should IMHO be addressed, rather than
> discussing existing code using sort().
That's fine, but since I don't _have_ "a problem" here I hope you'll
forgive me if I don't address it <grin>.
> [various ignore-return-value approaches deleted]
> IMHO, The correct answer to this slight problem in Python is probably
> to have some sort of statement that tosses the result of an
> evaluation. In C/C++, the *official* way to do this is by doing a
> cast to void:
>
> (void)f(x)
Something like that would be fine by me, although I can live without it.
> ...
> Finally, the *real* reason why I entered this thread is to push for
> being able to write the equivalent of:
>
> for i in foo.keys().sort():
> ...
Unless you're addicted to dangling-method _syntax_, it's easy to write
your own sort _function_ to do this. E.g, the following works fine
today:
def sort(sequence):
sequence.sort() # precede by "sequence = sequence[:]" for a copying sort
return sequence
for i in sort(foo.keys()):
...
So does the obvious:
keys = foo.keys()
keys.sort()
for i in keys:
...
You'd have a hard time making a serious argument that either of these
alternatives is _difficult_, and arguments based on style are a hard
sell.
> Note that IF a dup_sort() method was defined to return copy of self, then
> this "copying sort" could even be applied to immutable sequences...
See above for an easy way to write a sort function that does this.
> and the world would rejoice... and peace would rein... and ... (well,
> maybe I'm exaggerating a bit).
That is the problem! I.e., for just about any change anyone ever
suggests, _most_ of the world yawns. And that may be the only thing that
prevents all languages from becoming Common Lisp <0.5 grin> ...
not-all-good-or-all-bad-ly y'rs - tim
Tim Peters tim@ksr.com
not speaking for Kendall Square Research Corp