Why return None?
roy at panix.com
Wed Aug 25 14:59:07 CEST 2004
In article <uK%Wc.213074$gE.193548 at pd7tw3no>,
Martin DeMello <martindemello at yahoo.com> wrote:
> Dan Sommers <me at privacy.net> wrote:
> > If list.sort returned the sorted list, how many lists would there be
> > after this code executed?
> > original_list = a_function_that_returns_a_list( )
> > sorted_list = original_list.sort( )
> One - sorted_list would be a reference to the (now sorted) original
> list. The newbie problem could be solved by having <verb> and <verbed>
> versions of each destructive method - i.e. list.sort() to sort the list
> in-place and return it, and list.sorted() to return a new, sorted list,
> and experienced users could chain methods and all that other good stuff.
The problem with sort() vs. sorted() is that it's obscure. I'm not a
big fan of quoting gospel, but it seems to me that it violates the
gospel of "explicit is better than implicit".
If I took 10 programmers who were generally familiar with typical OO
syntax, but not specifically with Python and asked them what list.sort()
and list.sorted() did, I imagine all of them would say something like,
"Well, they both obviously sort a list, and clearly the existence of two
different methods means they do it differently somehow, but I can't for
the life of me guess what the difference is".
Explicit would be something like having two methods named in ways that
people could figure out without having to RTFM:
list.sort () ==> returns a sorted copy of the list
list.sort_in_place () ==> sorts in place, returns None
or if you prefer to do it the other way:
list.sort () ==> sorts in place, returns None
list.sort_copy () ==> returns a sorted copy of the list
But, personally, I find that all kind of silly; IMHO, list.sort ()
should have just returned self to begin with and then we wouldn't be
having this discussion.
More information about the Python-list