Why return None?

[Martin DeMello]

It seems to be a fairly common pattern for an object-modifying method to
return None - however, this is often quite inconvenient.

For instance

def f(lst1, lst2):
g((lst1 + lst2).reverse()) # doesn't work!

you need to say

def f(lst1, lst2):
a = lst1 + lst2
a.reverse()
g(a)

this is actually getting in my way a lot when scripting Blender - for
instance, I can't say move(Vector([a,b,c]).normalize()), I have to do
a = Vector([a,b,c])
a.normalize()
move(a)

but it seems to be recommended practice rather than a fault in the
Blender API, since the standard list does it. Is there any drawback to
returning self rather than None?

martin

c

 

[Anthony Baxter]

It seems to be a fairly common pattern for an object-modifying method to
return None - however, this is often quite inconvenient.

list.reverse() modifies the list in place. The python idiom is that
these don't return a reference to the modified list. Although note the
new list.sorted() method in 2.4...

Anthony

 

[Max M]

It seems to be a fairly common pattern for an object-modifying method to
return None - however, this is often quite inconvenient.

With newstyle classe you can subclass the list class and make some
functions return self.

class List(list):

def sort(self):
list.sort(self)
return self


l = List([1,2,4,2,5,2,6])
print l.sort()

>>>[1, 2, 2, 2, 4, 5, 6]

Well ok. Sort is a bad example, as you could just use sorted() insted.


regards Max M

 

[Martin DeMello]

list.reverse() modifies the list in place. The python idiom is that
these don't return a reference to the modified list. Although note the

Yes, but why? I mean, is there either an advantage to returning None or
some inherent danger in returning self?

martin

 

[Peter Otten]

Yes, but why? I mean, is there either an advantage to returning None or
some inherent danger in returning self?

martin

I think Guido would rather have newbies stumbling over
Traceback (most recent call last):
File "<stdin>", line 1, in ?
TypeError: zip argument #2 must support iteration

than
.... def reverse(self):
.... list.reverse(self)
.... return self
....[('c', 'c'), ('b', 'b'), ('a', 'a')]

The latter is more likely to remain undetected until some damage is done.
Still, I would prefer it.

Peter

 

[Benjamin Niemann]

Yes, but why? I mean, is there either an advantage to returning None or
some inherent danger in returning self?

The danger is that you might forget about the side effect.

l = [1, 2, 4, 3]
sorted = l.sort()
.... # do something with sorted list
print l # I want to unsorted list here, but oops...

In place object modification is often faster, but you loose the original
data - this should be explicitly visible in the code

 

[Max M]

Yes, but why? I mean, is there either an advantage to returning None or
some inherent danger in returning self?

It is a design philosophy. Explicit is better than implicit.

what would you expect a_list.sort() to return?

If it returns a list, you would expect it to be a sorted copy of the
list. Not the list itself.

But for performance reasons the list is sorted in place.

So if you modify the list in place, why should sort() then return the list?

That the sort() method returns a None is actually a pedagocical tool to
tell the programmer that the list is modified in place.

If it had returned the list the programmer would later be surprised to
find that the list had been modified. It would seem like hard to find
nasty side effect. The way it is now is very explicit and easy to find out.


regards Max M

 

[Dan Sommers]

Yes, but why? I mean, is there either an advantage to returning None or
some inherent danger in returning self?

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( )

HTH,
Dan

 

[Michael Hudson]

list.reverse() modifies the list in place. The python idiom is that
these don't return a reference to the modified list. Although note the
new list.sorted() method in 2.4...

It's a builtin now (as is reversed).

Cheers,
mwh

 

[Martin DeMello]

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.

martin

 

[Roy Smith]

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.

martin

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.

heretic-ly yours.

 

[Dave Opstad]

It is a design philosophy. Explicit is better than implicit.

what would you expect a_list.sort() to return?

If it returns a list, you would expect it to be a sorted copy of the
list. Not the list itself.

But for performance reasons the list is sorted in place.

So if you modify the list in place, why should sort() then return the list?

That the sort() method returns a None is actually a pedagocical tool to
tell the programmer that the list is modified in place.

If it had returned the list the programmer would later be surprised to
find that the list had been modified. It would seem like hard to find
nasty side effect. The way it is now is very explicit and easy to find out.

But isn't the fact that the list is modified in place incidental to the
fact of sorting? One is an implementation detail, and the other is the
semantic meaning you're trying to express.

In my opinion, it would make more sense to have:

[1, 3, 4, 2].sort() return [1, 2, 3, 4]
(1, 3, 4, 2).sort() return (1, 2, 3, 4)
'1342'.sort() return '1234'

and so on. As it is, we have sort working on lists but not on immutable
sequences, which is inconvenient at times.

Just my tuppence.
Dave

 

[Mel Wilson]

But isn't the fact that the list is modified in place incidental to the
fact of sorting? One is an implementation detail, and the other is the
semantic meaning you're trying to express.

It's not incidental to the fact that the original list is
"destroyed" by the sorting operation.

Regards. Mel.

 

[Ayose]

[Martin DeMello]

It seems to be a fairly common pattern for an object-modifying method to
return None - however, this is often quite inconvenient.

For instance

def f(lst1, lst2):
g((lst1 + lst2).reverse()) # doesn't work!

If you can use python 2.3 or newer, try with [::-1]
... print (m + n)[::-1]
...

>>> f([1,2,3], [10,20,30]) [30, 20, 10, 3, 2, 1]
>>>

 

[Dan Bishop]

[discussion of why list.sort returns None instead of a list]

But isn't the fact that the list is modified in place incidental to the
fact of sorting? One is an implementation detail, and the other is the
semantic meaning you're trying to express.

The fact that the list is sorted in-place *is* semantically
meaningful. It's often important to know whether the original list is
sorted or not.

 

[Martin DeMello]

But isn't the fact that the list is modified in place incidental to the
fact of sorting? One is an implementation detail, and the other is the
semantic meaning you're trying to express.

Nope, especially since objects are passed by reference.

In my opinion, it would make more sense to have:

[1, 3, 4, 2].sort() return [1, 2, 3, 4]
(1, 3, 4, 2).sort() return (1, 2, 3, 4)
'1342'.sort() return '1234'

and so on. As it is, we have sort working on lists but not on immutable
sequences, which is inconvenient at times.

This again would be a difference between sort() and sorted().

My main point is that returning None is pretty useless - it 'wastes' the
return value, and doesn't allow method chaining. Returning self allows
you to either use or discard the return value depending on whether
you're interested in it, whereas using None doesn't give you any choice.

martin

 

[Martin DeMello]

If you can use python 2.3 or newer, try with [::-1]
... print (m + n)[::-1]
...

f([1,2,3], [10,20,30])

[30, 20, 10, 3, 2, 1]

Thanks! Where can I look this up?

martin

 

[Erik Max Francis]

Yes, but why? I mean, is there either an advantage to returning None
or
some inherent danger in returning self?

The "inherent danger" is that the user might think that it returns a new
object rather than mutating the original. Returning a new object vs.
mutating the argument and returning None is merely a convention, but
it's one used consistently in the Python standard library.

 

[Raymond Hettinger]

It seems to be a fairly common pattern for an object-modifying method to
return None - however, this is often quite inconvenient.

The FAQs provide a clue to Guido's thinking on this subject:

http://www.python.org/doc/faq/general.html#why-doesn-t-list-sort-return-the-sorted-list



Raymond Hettinger

 

[Peter Hansen]

It seems to be a fairly common pattern for an object-modifying method to
return None - however, this is often quite inconvenient.

http://www.python.org/doc/faq/general.html#why-doesn-t-list-sort-return-the-sorted-list

(Not an answer to the general question you ask, unless you
extrapolate from the specific answer given there to the
more general case.)

-Peter