Re: [Python-Dev] Merge conflicts from unmerged 3.4 commits, what do I do?
On 5/19/2014 2:08 AM, Terry Reedy wrote: On 5/19/2014 1:31 AM, Raymond Hettinger wrote: To get my repo back into a usable state, I ran "hg update --clean" py35% hg update --clean % hg update --clean abort: index 00changelog.i unknown format 2! After exiting Workbench and rebooting, update --clean worked fine. -- 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
Re: [Python-Dev] Returning None from methods that mutate object state
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
Re: [Python-Dev] Returning None from methods that mutate object state
>
> [].sort() is None
> > True
> "ABC".lower() is None
> > False
> >
> > That's a deliberate design choice, and one that has been explained a
> > few times on the list when folks ask why "[].sort().reverse()" doesn't
> > work when "'ABC'.lower().replace('-', '_')" does.
> >
> > Would it be worth adding such a note? Or is it out of scope?
>
Is there a reference anywhere as to *why* the convention in Python is to do
it that way?
Personally, I often miss the ability to chain operations on mutable
objects, but I can only imagine that that design decision was made for good
reason. However, as I teach Python, I find I have nothing to say other than
"that's the way it's done in Python".
I note in a way that there is a bit of backwards logic:
immutable objects **have** to return something, so they naturally chain.
It's almost as if the philosophy of the language is that you don't want
chaining behavior, and it's really just a side effect of immutables that
you get it with them.
I suppose the argument could be that for mutable objects, returning None is
an indicator that you are a) working with an mutable object, and b) that
the method changes the internal state. But the .pop() example demonstrates
that a method can both return something meaningful, and change internal
state, so I'm not sure it's really a distinction worth making.
So again: is there a clear explanation of the logic behind the convention
posted somewhere?
-Chris
--
Christopher Barker, Ph.D.
Oceanographer
Emergency Response Division
NOAA/NOS/OR&R(206) 526-6959 voice
7600 Sand Point Way NE (206) 526-6329 fax
Seattle, WA 98115 (206) 526-6317 main reception
chris.bar...@noaa.gov
___
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
Re: [Python-Dev] Returning None from methods that mutate object state
Chris Barker wrote: Personally, I often miss the ability to chain operations on mutable objects, but I can only imagine that that design decision was made for good reason. However, as I teach Python, I find I have nothing to say other than "that's the way it's done in Python". Python has better ways of doing many of the things that method chaining is used for in other languages. In Java, for example, I often see it used as a somewhat klunky workaround for the lack of keyword arguments when initialising objects. Other than that, it seems to be mainly for stuffing multiple operations into one line, which is not something the Python style generally goes in for. I suppose the argument could be that for mutable objects, returning None is an indicator that you are a) working with an mutable object, and b) that the method changes the internal state. But the .pop() example demonstrates that a method can both return something meaningful, and change internal state, so I'm not sure it's really a distinction worth making. It's not just about mutating the object, it's about a mutating method with a name that could also plausibly be the name of a non-mutating method. The canonical example is sort(), which, if you didn't already know, could equally well be mutating or non-mutating. In those cases, I think it's worth making it difficult to get wrong. This doesn't apply so much to pop(), which sounds much more like a mutating method than a non-mutating one, so it's less likely you'll make a mistake. -- Greg ___ 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
Re: [Python-Dev] Returning None from methods that mutate object state
On Tue, 20 May 2014 09:30:47 -0700, Chris Barker wrote:
> >
> > [].sort() is None
> > > True
> > "ABC".lower() is None
> > > False
> > >
> > > That's a deliberate design choice, and one that has been explained a
> > > few times on the list when folks ask why "[].sort().reverse()" doesn't
> > > work when "'ABC'.lower().replace('-', '_')" does.
> > >
> > > Would it be worth adding such a note? Or is it out of scope?
> >
>
> Is there a reference anywhere as to *why* the convention in Python is to do
> it that way?
>
> Personally, I often miss the ability to chain operations on mutable
> objects, but I can only imagine that that design decision was made for good
> reason. However, as I teach Python, I find I have nothing to say other than
> "that's the way it's done in Python".
>
> I note in a way that there is a bit of backwards logic:
>
> immutable objects **have** to return something, so they naturally chain.
> It's almost as if the philosophy of the language is that you don't want
> chaining behavior, and it's really just a side effect of immutables that
> you get it with them.
>
> I suppose the argument could be that for mutable objects, returning None is
> an indicator that you are a) working with an mutable object, and b) that
> the method changes the internal state. But the .pop() example demonstrates
> that a method can both return something meaningful, and change internal
> state, so I'm not sure it's really a distinction worth making.
>
> So again: is there a clear explanation of the logic behind the convention
> posted somewhere?
I think it is exactly about not encouraging chaining of mutations, but I
could be wrong :)
--David
___
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
Re: [Python-Dev] Returning None from methods that mutate object state
On 5/20/2014 12:30 PM, Chris Barker wrote:
[].sort() is None
> True
"ABC".lower() is None
> False
Is there a reference anywhere as to *why* the convention in Python is to
do it that way?
In short, reducing bugs induced by mutation of aliased objects.
Functional languages evade the problem by prohibiting mutation
(sometimes at the cost of inefficiency).
In an alternate universe, the example above might become
>>> a = []; a.sort() is a
True
>>> a = "ABC"' a.lower() is a
False
As I suggested earlier, having pure mutation methods not return anything
made is easy to suggest a mutation + non-self return method, list.pop.
If all mutation methods had previously returned 'self', there might have
been disagreement over whether the item return should augment or replace
the self return. Before you say the latter, consider the inconsistency
of only sometimes returning self and the potential consistency between
>>> most, last = 'a b c'.rsplit(maxsplit=1)
>>> most, last
('a b', 'c')
>>> most, last = [0, 1, 2].pop()
>>> most, last
([0, 1], 2)
One could also consider first, rest pairings.
--
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
Re: [Python-Dev] Returning None from methods that mutate object state
On Tuesday, May 20, 2014, Greg Ewing wrote: > Chris Barker wrote: > >> Personally, I often miss the ability to chain operations on mutable >> objects, but I can only imagine that that design decision was made for good >> reason. However, as I teach Python, I find I have nothing to say other than >> "that's the way it's done in Python". >> > > Python has better ways of doing many of the things that > method chaining is used for in other languages. In Java, > for example, I often see it used as a somewhat klunky > workaround for the lack of keyword arguments when > initialising objects. > > Other than that, it seems to be mainly for stuffing > multiple operations into one line, which is not something > the Python style generally goes in for. > > I suppose the argument could be that for mutable objects, returning None >> is an indicator that you are a) working with an mutable object, and b) that >> the method changes the internal state. But the .pop() example demonstrates >> that a method can both return something meaningful, and change internal >> state, so I'm not sure it's really a distinction worth making. >> > > It's not just about mutating the object, it's about a > mutating method with a name that could also plausibly > be the name of a non-mutating method. The canonical > example is sort(), which, if you didn't already know, > could equally well be mutating or non-mutating. In > those cases, I think it's worth making it difficult > to get wrong. This is the key reason, by far the most important. > This doesn't apply so much to pop(), which sounds > much more like a mutating method than a non-mutating > one, so it's less likely you'll make a mistake. > > -- > Greg > ___ > 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/ > guido%40python.org > -- --Guido van Rossum (on iPad) ___ 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
