Jean-Paul Calderone <[email protected]> added the comment:
> The argument that "there are already two ways to do it, so why add a third?",
> is not bad, but if applied to appending, it would ban the append() method...
> except that it's already there.
Not quite. First let's consider the insert approach. Unlike with prepending,
you first have to find the length of the list: L.insert(len(L), x). So it's no
longer just a matter of an extra constant (although it /is/ still pretty
simple). Next, the slice assignment solution: L[-1:] = [x] doesn't work,
because it actually includes the last element of L in the slice, so it replaces
the last value instead of appending the new element.
So there's really just two ways, L.insert(len(L), x) and L.append(x). To me,
it seems like the extra cognitive load of figuring out whether the parameter to
L.insert should be len(L) or len(L) - 1 or len(L) + 1 makes L.append
worthwhile. Maybe the same argument could be applied to L.insert(0, x), but it
seems like a simpler case ("of _course_ inserting at 0 prepends") to me.
The other cost of adding a new list method is updating all of the list-like
interfaces out there to also provide this, although that would probably be a
cost worth accepting for a really compelling new method.
> Sorry to bring up this issue that I guess has been raised (many times?)
> before, but I thought I'd have a stab at a convincing case!
No need to apologize! Thanks for the reasoned argument. At least this can
serve as a reference when the issue comes up again in the future, and perhaps
someone else will be more convinced than overrule me. :)
----------
_______________________________________
Python tracker <[email protected]>
<http://bugs.python.org/issue9080>
_______________________________________
_______________________________________________
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
