[Python-Dev] Returning None from methods that mutate object state

[Terry Reedy]

On 5/19/2014 10:20 AM, Hrvoje Niksic wrote:
> On 05/17/2014 10:26 AM, Terry Reedy wrote:
>  > When list.pop was added, the convention was changed to
>  > "do not return the 'self' parameter"
>
> Do you have a reference for this?

I think the fact that Guido accepted, in 2000, my 1999 proposal, with 
generalizations, at Tim Peter's suggestion, and that other pop methods 
and iterator.__next__ methods have been added since, speaks for itself.

However, here is the reference to my original PEP-like post and the 
subsequent discussion. I consider the subthread about the convention as 
the most important part of the discussion, as I considered it the most 
salient objection to the proposal.

https://groups.google.com/forum/#!topic/comp.lang.python/SKJq3S2ZYmg

Mike Meyer said "While I personally like the idea of a .pop method for 
lists, it seems to violate one of the design principles that Guido uses: 
that methods either modify objects, or return values from/about it, but 
not both."

John (Max) Skaller, in his second response, noted that Alex Stepanov 
used the same principle when designing STL, but the C++ modified his 
design for convenience and efficiency.

In my first response, I suggested that if a convention prevents writing 
a proper stack, queue, or deque class, all of which are computer science 
standards, or if a convention prevents pairing a inverse with a 
function, as is standard in mathematics, then the convention should be 
re-examined.

In Guido's first response he settled the particular question by saying 
"To implement a stack, one would need to add a list.pop() primitive
(and no, I'm not against this particular one on the basis of any
principle)."  At the time, he was just more inclined "to leave the list 
data type alone and implement a stack as a class that uses a list for 
its representation."

That covers half the thread.

 > It is my understanding that the
> convention is for mutators to return None,

I would say that the convention was to return nothing, which in Python 
means accepting the default return of None. In a language that allowed 
procedure methods, there would literally be no return. Python's 
interactive read-eval-print loop does not print None because it usually 
represents a non-return.

 > in order to make it clear that the change is destructive.

and in particular, to disallow chaining by not returning 'self'.

 > For example, the tutorial at
> https://docs.python.org/3.4/tutorial/datastructures.html says:
>
> """
> You might have noticed that methods like insert, remove or sort that
> modify the list have no return value printed – they return None. [1]
> This is a design principle for all mutable data structures in Python.
> """

Good catch. This only needs 'only' inserted before 'modify' to become 
true again. I opened http://bugs.python.org/issue21545
Note that the point of the comment is to explain the apparent absence of 
a return in the r.e.p. loop, the same as in a language with no-return 
procedures.

 >>> a.sort()
 >>>

-- 
Terry Jan Reedy