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
_______________________________________________
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
