Thoughts on List Methods and Return Values

[Alex Martelli]

"Tim Peters" <tim.one at home.com> wrote in message
news:mailman.982439002.3211.python-list at python.org...
    [snip]
> > 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
    [snip]
> [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.:
    [snip]
> 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
rather kludgey!

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


Alex