Thoughts on List Methods and Return Values
aleaxit at yahoo.com
Sat Feb 17 23:06:25 CET 2001
"Tim Peters" <tim.one at home.com> wrote in message
news:mailman.982439002.3211.python-list at python.org...
> > Which leads me to the thought that if *all* the methods which now return
> > None were to modify the list in place as well as return the modified
> > list, we would soon get used to this behaviour and achieve some coding
> [Alex Martelli]
> > Quite apart from any evaluation of this proposal, I fail to see
> > what 'lot of code' could possibly be broken by this change. Is
> > there a 'lot of code' _relying_ on the None return, e.g.:
> In a roundabout way, yes:
> >>> x = [random.random() for i in xrange(1000000)]
> >>> x.sort()
> Oops! Guess what that does to your interactive session if x.sort() starts
That's not "lots of code" that's going to be broken -- it's a currently
OK interactive-interpreter idiom that becomes non-ok (to be replaced
with, e.g., _=x.sort(), or whatever). [Actually, it becomes OK again
if one uses the new interactive-session hook to prettyprint stuff returned
by interactive-session expressions, rather than just printing its repr, of
course; in fact, with a suitable prettyprint, it becomes a _plus_, since
one can see what's happening step by step as a list gets modified -- I
would argue that's a larger plus, e.g. for beginners' self-instruction,
than being able to chain calls...!-)].
> to return x. People using my doctest.py would find that tons of their
> docstring examples "suddenly don't work" because of that too.
That's more serious, and I wish I had thought of that since I'm quite
an aficionado of your doctest.py. The fixes I can think of would be
> BTW, it's not just lists, it's all mutate-in-place methods of all builtin
> types that return None.
Well, ALMOST all -- dict.setdefault 'may' mutate-in-place and may
not return None. But that's a rather special case, of course.
More information about the Python-list