Suggestion: push() method for lists
It would be nice to have the opposite of the pop() method: a push() method. While insert() and append() already exist, neither is the opposite of pop(). pop() has a default index parameter -1, but neither insert() nor append() has a default index parameter. push(obj) would be equivalent to insert(index = -1, object), having -1 as the default index parameter. In fact, push() could replace both append() and insert() by unifying them. By default push(obj) would insert an object to the end of the list, while push(obj, index) would insert the object at index, just like pop() removes (and returns) the object at the end of the list, and pop(index) removes (and returns) the object at the index. I found little discussion on this, just this SO thread http://stackoverflow.com/questions/1566266/why-is-pythons-append-not-push which lead to a discussion from 20 years ago (1997): <https://groups.google.com/forum/#!topic/comp.lang.python/SKJq3S2ZYm> https://groups.google.com/forum/#!topic/comp.lang.python/SKJq3S2ZYmg <https://groups.google.com/forum/#!topic/comp.lang.python/SKJq3S2ZYmg> Some key arguments from the thread: >it would be an >easy and obvious improvement to make popend an explicit builtin, and >that this would make Python even more attractive to newcomers who want >to use what they already know and be immediately productive. - Terry Reedy >append() is a special case of insert(). The inverse of insert() is >the del function. The specific inverse of append() is del list[-1]. - Michael W. Ryan >but I'm not a big fan of multiple names for the same operation -- >sooner or later you're going to read code that uses the other one, so >you need to learn both, which is more cognitive load. - Guido van Rossum So while it has been discussed before, it's worth bringing up again, since this was before the release of Python 2.0. Pros: - Would simplify the language by having a symmetric relation to pop(). - Would make it easy to use lists as stacks. - Saves at least two characters - If append()/insert() are being removed and replaced, the complexity of lists is slightly reduced. Cons: - Would blur the line between lists and stacks. - The order of the parameters in push(obj, index = -1) would be the opposite of the parameters in insert(index, obj), because defaulted parameters come last. - If append()/insert() are being removed and replaced, backwards compatability breaks. - If append()/insert() are kept instead of being replaced, the complexity of lists is slightly increased. While it isn't a necessity, I believe the benefit of push() method outweighs its cons. ~Paul
On Sun, May 21, 2017 at 10:43 AM, Paul Laos <paul_laos@outlook.com> wrote: > It would be nice to have the opposite of the pop() method: a push() > method. While insert() and append() already exist, neither is the opposite > of pop(). pop() has a default index parameter -1, but neither insert() nor > append() has a default index parameter. push(obj) would be equivalent to > insert(index = -1, object), having -1 as the default index parameter. In > fact, push() could replace both append() and insert() by unifying them. > > > By default push(obj) would insert an object to the end of the list, while > push(obj, index) would insert the object at index, just like pop() removes > (and returns) the object at the end of the list, and pop(index) removes > (and returns) the object at the index. > > > I found little discussion on this, just this SO thread > http://stackoverflow.com/questions/1566266/why-is-pythons-append-not-push which > lead to a discussion from 20 years ago (1997): > <https://groups.google.com/forum/#!topic/comp.lang.python/SKJq3S2ZYm> > https://groups.google.com/forum/#!topic/comp.lang.python/SKJq3S2ZYmg > <https://groups.google.com/forum/#!topic/comp.lang.python/SKJq3S2ZYmg> > > > Some key arguments from the thread: > > > >it would be an > >easy and obvious improvement to make popend an explicit builtin, and > >that this would make Python even more attractive to newcomers who want > >to use what they already know and be immediately productive. > - Terry Reedy > > > >append() is a special case of insert(). The inverse of insert() is > >the del function. The specific inverse of append() is del list[-1]. > - Michael W. Ryan > > >but I'm not a big fan of multiple names for the same operation -- > >sooner or later you're going to read code that uses the other one, so > >you need to learn both, which is more cognitive load. > - Guido van Rossum > > > So while it has been discussed before, it's worth bringing up again, since > this was before the release of Python 2.0. > > Pros: > > - Would simplify the language by having a symmetric relation to pop(). > > - Would make it easy to use lists as stacks. > > - Saves at least two characters > > - If append()/insert() are being removed and replaced, the complexity of > lists is slightly reduced. > > > Cons: > > - Would blur the line between lists and stacks. > > - The order of the parameters in push(obj, index = -1) would be the > opposite of the parameters in insert(index, obj), because defaulted > parameters come last. > > - If append()/insert() are being removed and replaced, backwards > compatability breaks. > > - If append()/insert() are kept instead of being replaced, the complexity > of lists is slightly increased. > > > While it isn't a necessity, I believe the benefit of push() method > outweighs its cons. > There is absolutely zero chance that append and insert are going away. That would break everything. So with your proposal, we would end up with two methods that do exactly the same thing, differing only in the defaults and the order of arguments. That definitely does not make the language simpler. The big question you need to ask when proposing a new feature for python is "what is the use-case for this?" What does this do that existing features can't do, or that existing features are significantly worse at? Since this literally duplicates the functionality of existing features, it doesn't have such a use-case If we were changing things at all, I think the first place to start would be to either set a default argument for "insert" or add an optional argument for "append", but in both cases that would again be duplicating functionality so I don't see the point.
On 22 May 2017 at 00:43, Paul Laos <paul_laos@outlook.com> wrote:
So while it has been discussed before, it's worth bringing up again, since this was before the release of Python 2.0.
It was also before the addition of collections.deque. which uses appendleft() and extendleft(), rather than pushleft().
I think the key argument here would be that *for folks that already know the push/pop terminology for stack data structures*, "push" is a potentially more intuitive term than the insert/append/extend trio. However, for most people, "append an item to a list", "insert an item into a list" and "extend a list" are common English phrases, while "push an item onto a list" would get you funny looks, and even "push an item onto a stack" would be unusual in a spoken conversation (the non-jargon phrase in that case is "add an item to the stack", but "add" would be ambiguous between the append() and extend() meanings) As a result, the specific-to-computer-science jargon loses out. The situation for `pop()` is different, as `remove()` is already taken for "remove an item from the list by value", so a different word is needed for "remove an item from the list by index".
- If append()/insert() are being removed and replaced, the complexity of lists is slightly reduced.
There's zero chance of the existing APIs going away - they're not broken, and they match common English phrasing. The fact they don't match common computer science jargon isn't ideal, but it's relevatively straightforward to define a stack data structure if someone really wants to do so.
While I don't think it makes sense to add the method in the first place, if we did, it either wouldn't accept an index parameter, or else the index parameter would be a keyword-only argument. Cheers, Nick. -- Nick Coghlan | ncoghlan@gmail.com | Brisbane, Australia
I think the first place to start would be to either set a default argument for "insert"
or add an optional argument for "append", but in both cases that would again be
duplicating functionality so I don't see the point.
- Todd That would be fine too; the main idea is just having a method that's symmetrically related to pop(). append(2, 2) would seem awkward, but it could work with insert(2).
-Nick Coghlan This is an interesting argument, because English isn't my first language, so it's not something I would think of. Having a programming language obey the laws of spoken English seems uncalled for, but it's still a good point. The name could be something more natural, of course. (Even so, is "pop() an item from a list" any better?)
There is absolutely zero chance that append and insert are going away. That would break everything.
- Todd
There's zero chance of the existing APIs going away
- Nick Coghlan It was hypothetical, but you're probably right.
I don't think it makes sense to add the method
- Nick Coghlan It makes sense to have inverse methods. pop() pops off the last item and pop(i) pops off the ith item. There are no methods such that push(obj) pushes the item onto the end and push(obj, index) pushes the item onto the ith position. That would be append(obj) and insert(obj, index), but there's no symmetric relation here. This is harder to learn, so it would be better to have a unified method for the inverse. Todd's suggestion of letting the index parameter for insert() be optional would accomplish the same result, without having to add an additional method. ~Paul ________________________________ From: Nick Coghlan <ncoghlan@gmail.com> Sent: Monday, May 22, 2017 7:47:42 AM To: Paul Laos Cc: python-ideas@python.org Subject: Re: [Python-ideas] Suggestion: push() method for lists On 22 May 2017 at 00:43, Paul Laos <paul_laos@outlook.com> wrote:
So while it has been discussed before, it's worth bringing up again, since this was before the release of Python 2.0.
It was also before the addition of collections.deque. which uses appendleft() and extendleft(), rather than pushleft().
I think the key argument here would be that *for folks that already know the push/pop terminology for stack data structures*, "push" is a potentially more intuitive term than the insert/append/extend trio. However, for most people, "append an item to a list", "insert an item into a list" and "extend a list" are common English phrases, while "push an item onto a list" would get you funny looks, and even "push an item onto a stack" would be unusual in a spoken conversation (the non-jargon phrase in that case is "add an item to the stack", but "add" would be ambiguous between the append() and extend() meanings) As a result, the specific-to-computer-science jargon loses out. The situation for `pop()` is different, as `remove()` is already taken for "remove an item from the list by value", so a different word is needed for "remove an item from the list by index".
- If append()/insert() are being removed and replaced, the complexity of lists is slightly reduced.
There's zero chance of the existing APIs going away - they're not broken, and they match common English phrasing. The fact they don't match common computer science jargon isn't ideal, but it's relevatively straightforward to define a stack data structure if someone really wants to do so.
While I don't think it makes sense to add the method in the first place, if we did, it either wouldn't accept an index parameter, or else the index parameter would be a keyword-only argument. Cheers, Nick. -- Nick Coghlan | ncoghlan@gmail.com | Brisbane, Australia
On 21/05/17 15:43, Paul Laos wrote:
I don't think list.insert() with an index of -1 does what you think it does: $ python3 Python 3.5.2 (default, Nov 17 2016, 17:05:23) [GCC 5.4.0 20160609] on linux Type "help", "copyright", "credits" or "license" for more information.
Because the indices can be thought of as referencing the spaces _between_ the objects, having a push() in which -1 is referencing a different 'space' than a -1 given to insert() or a slice operation refers to would, I suspect, be a source of confusion (and off-by-one bugs). E.
On Sun, May 21, 2017 at 10:43 AM, Paul Laos <paul_laos@outlook.com> wrote: > It would be nice to have the opposite of the pop() method: a push() > method. While insert() and append() already exist, neither is the opposite > of pop(). pop() has a default index parameter -1, but neither insert() nor > append() has a default index parameter. push(obj) would be equivalent to > insert(index = -1, object), having -1 as the default index parameter. In > fact, push() could replace both append() and insert() by unifying them. > > > By default push(obj) would insert an object to the end of the list, while > push(obj, index) would insert the object at index, just like pop() removes > (and returns) the object at the end of the list, and pop(index) removes > (and returns) the object at the index. > > > I found little discussion on this, just this SO thread > http://stackoverflow.com/questions/1566266/why-is-pythons-append-not-push which > lead to a discussion from 20 years ago (1997): > <https://groups.google.com/forum/#!topic/comp.lang.python/SKJq3S2ZYm> > https://groups.google.com/forum/#!topic/comp.lang.python/SKJq3S2ZYmg > <https://groups.google.com/forum/#!topic/comp.lang.python/SKJq3S2ZYmg> > > > Some key arguments from the thread: > > > >it would be an > >easy and obvious improvement to make popend an explicit builtin, and > >that this would make Python even more attractive to newcomers who want > >to use what they already know and be immediately productive. > - Terry Reedy > > > >append() is a special case of insert(). The inverse of insert() is > >the del function. The specific inverse of append() is del list[-1]. > - Michael W. Ryan > > >but I'm not a big fan of multiple names for the same operation -- > >sooner or later you're going to read code that uses the other one, so > >you need to learn both, which is more cognitive load. > - Guido van Rossum > > > So while it has been discussed before, it's worth bringing up again, since > this was before the release of Python 2.0. > > Pros: > > - Would simplify the language by having a symmetric relation to pop(). > > - Would make it easy to use lists as stacks. > > - Saves at least two characters > > - If append()/insert() are being removed and replaced, the complexity of > lists is slightly reduced. > > > Cons: > > - Would blur the line between lists and stacks. > > - The order of the parameters in push(obj, index = -1) would be the > opposite of the parameters in insert(index, obj), because defaulted > parameters come last. > > - If append()/insert() are being removed and replaced, backwards > compatability breaks. > > - If append()/insert() are kept instead of being replaced, the complexity > of lists is slightly increased. > > > While it isn't a necessity, I believe the benefit of push() method > outweighs its cons. > There is absolutely zero chance that append and insert are going away. That would break everything. So with your proposal, we would end up with two methods that do exactly the same thing, differing only in the defaults and the order of arguments. That definitely does not make the language simpler. The big question you need to ask when proposing a new feature for python is "what is the use-case for this?" What does this do that existing features can't do, or that existing features are significantly worse at? Since this literally duplicates the functionality of existing features, it doesn't have such a use-case If we were changing things at all, I think the first place to start would be to either set a default argument for "insert" or add an optional argument for "append", but in both cases that would again be duplicating functionality so I don't see the point.
On 22 May 2017 at 00:43, Paul Laos <paul_laos@outlook.com> wrote:
So while it has been discussed before, it's worth bringing up again, since this was before the release of Python 2.0.
It was also before the addition of collections.deque. which uses appendleft() and extendleft(), rather than pushleft().
I think the key argument here would be that *for folks that already know the push/pop terminology for stack data structures*, "push" is a potentially more intuitive term than the insert/append/extend trio. However, for most people, "append an item to a list", "insert an item into a list" and "extend a list" are common English phrases, while "push an item onto a list" would get you funny looks, and even "push an item onto a stack" would be unusual in a spoken conversation (the non-jargon phrase in that case is "add an item to the stack", but "add" would be ambiguous between the append() and extend() meanings) As a result, the specific-to-computer-science jargon loses out. The situation for `pop()` is different, as `remove()` is already taken for "remove an item from the list by value", so a different word is needed for "remove an item from the list by index".
- If append()/insert() are being removed and replaced, the complexity of lists is slightly reduced.
There's zero chance of the existing APIs going away - they're not broken, and they match common English phrasing. The fact they don't match common computer science jargon isn't ideal, but it's relevatively straightforward to define a stack data structure if someone really wants to do so.
While I don't think it makes sense to add the method in the first place, if we did, it either wouldn't accept an index parameter, or else the index parameter would be a keyword-only argument. Cheers, Nick. -- Nick Coghlan | ncoghlan@gmail.com | Brisbane, Australia
I think the first place to start would be to either set a default argument for "insert"
or add an optional argument for "append", but in both cases that would again be
duplicating functionality so I don't see the point.
- Todd That would be fine too; the main idea is just having a method that's symmetrically related to pop(). append(2, 2) would seem awkward, but it could work with insert(2).
-Nick Coghlan This is an interesting argument, because English isn't my first language, so it's not something I would think of. Having a programming language obey the laws of spoken English seems uncalled for, but it's still a good point. The name could be something more natural, of course. (Even so, is "pop() an item from a list" any better?)
There is absolutely zero chance that append and insert are going away. That would break everything.
- Todd
There's zero chance of the existing APIs going away
- Nick Coghlan It was hypothetical, but you're probably right.
I don't think it makes sense to add the method
- Nick Coghlan It makes sense to have inverse methods. pop() pops off the last item and pop(i) pops off the ith item. There are no methods such that push(obj) pushes the item onto the end and push(obj, index) pushes the item onto the ith position. That would be append(obj) and insert(obj, index), but there's no symmetric relation here. This is harder to learn, so it would be better to have a unified method for the inverse. Todd's suggestion of letting the index parameter for insert() be optional would accomplish the same result, without having to add an additional method. ~Paul ________________________________ From: Nick Coghlan <ncoghlan@gmail.com> Sent: Monday, May 22, 2017 7:47:42 AM To: Paul Laos Cc: python-ideas@python.org Subject: Re: [Python-ideas] Suggestion: push() method for lists On 22 May 2017 at 00:43, Paul Laos <paul_laos@outlook.com> wrote:
So while it has been discussed before, it's worth bringing up again, since this was before the release of Python 2.0.
It was also before the addition of collections.deque. which uses appendleft() and extendleft(), rather than pushleft().
I think the key argument here would be that *for folks that already know the push/pop terminology for stack data structures*, "push" is a potentially more intuitive term than the insert/append/extend trio. However, for most people, "append an item to a list", "insert an item into a list" and "extend a list" are common English phrases, while "push an item onto a list" would get you funny looks, and even "push an item onto a stack" would be unusual in a spoken conversation (the non-jargon phrase in that case is "add an item to the stack", but "add" would be ambiguous between the append() and extend() meanings) As a result, the specific-to-computer-science jargon loses out. The situation for `pop()` is different, as `remove()` is already taken for "remove an item from the list by value", so a different word is needed for "remove an item from the list by index".
- If append()/insert() are being removed and replaced, the complexity of lists is slightly reduced.
There's zero chance of the existing APIs going away - they're not broken, and they match common English phrasing. The fact they don't match common computer science jargon isn't ideal, but it's relevatively straightforward to define a stack data structure if someone really wants to do so.
While I don't think it makes sense to add the method in the first place, if we did, it either wouldn't accept an index parameter, or else the index parameter would be a keyword-only argument. Cheers, Nick. -- Nick Coghlan | ncoghlan@gmail.com | Brisbane, Australia
On 21/05/17 15:43, Paul Laos wrote:
I don't think list.insert() with an index of -1 does what you think it does: $ python3 Python 3.5.2 (default, Nov 17 2016, 17:05:23) [GCC 5.4.0 20160609] on linux Type "help", "copyright", "credits" or "license" for more information.
Because the indices can be thought of as referencing the spaces _between_ the objects, having a push() in which -1 is referencing a different 'space' than a -1 given to insert() or a slice operation refers to would, I suspect, be a source of confusion (and off-by-one bugs). E.
participants (5)
-
Erik -
Juancarlo Añez -
Nick Coghlan -
Paul Laos -
Todd