I would like to propose adding appendright() and popright() as optional aliases for deque.append() and deque.pop().
Since deque already has appendleft() and popleft(), adding explicit right-side aliases would make the API more symmetric and easier for beginners to understand.
The existing append() and pop()methods would remain unchanged, so this would not break compatibility.
Recently, re.match acquired the alias re.prefixmatch (see this topic). That topic originally proposed to deprecate the original, which you don’t, but even when softened to two equivalent names forever, evidence was required that the original name caused confusion and was named differently in other ecosystems.
I expect the same burden of proof to be required here, so I’d advise you to strengthen your case by providing some pointers to why append/popright names are more right (pun intended).
Personally, I think that append has a very clear meaning of “add to the end”, and “the end” has a strong association with the right (because we write left to right).
On the other hand, pop has no natural association for me. The fact that popleft exists is enough to remind me that an unadorned pop means pop from the right, but that’s very much logical deduction rather than intuition. Also, the fact that lists have a pop method that means “pop from the end” makes it much easier to remember.
Overall, I’m -1 on appendright, I don’t think it adds enough to be worthwhile. I would be -0 on popright in isolation, but because it makes little sense without a corresponding appendright, I’m -1 for this as well.
Personally, I think that
appendhas a very clear meaning of “add to the end”, and “the end” has a strong association with the right (because we write left to right).
Internationally speaking, it’s not necessarily “clear” since some cultures write top-to-bottom and some right-to-left.
I knew that and considered qualifying my statement, but decided that too many caveats would just obscure my point. Python is written left to right, because the keywords are written in English.
But yes, clarity is always in the eye of the beholder. I’m still -1 on the proposal though.
But logically there is still a “beginning” and an “end”. One could argue that right-to-left languages are a reason not to use words like “left” and “right” to refer to the start and end of a list, but there’s so many places where Python itself is left-to-right that the association is still strong. In any case, “append” is strongly associated with the end of something, with “prepend” if you want to stick something onto the beginning; so if there’s any reason to try to fix names to avoid left/right confusion, the answer wouldn’t be appendleft/appendright, it would be append/prepend.
Im not a native speaker. From my point of view is a left/right symmetry undesirable. I don’t mentally see the names divided into a left and right group. Rather, I see them as short names and long names, where the short names are short because they are expected to be used often, because they operate on the “usual” end for push/pop/append/etc. actions., i.e. the right end. The long names represent the opposite.
Yet one argument against popright. With popleft and popright you no longer know from what end pop works.
Thanks everyone for the explanations.
I now understand the main objection better. append() and pop() are consistent with the existing Python list convention, and adding appendright() / popright() would increase the public API surface for aliases of existing behavior.
My original concern was from a beginner/discoverability perspective: appendleft() and popleft() expose the endpoint in the method name, while append() and pop() rely on the existing Python convention. I still think that is a reasonable question to raise, but I agree that I do not have a strong enough case to justify adding new aliases.
Thanks again for the discussion.
If these get added, extendright probably should get as well.