Tim Wintle schrieb:
On Sat, 2009-04-04 at 02:03 -0500, Robert Kern wrote:
Let's be clear: python-ideas seems positive on the idea of adding a .clear()
method. *Completely removing* slice assignment has not been broached there.
Yup, sorry - I did mean to refer to the initial suggestion, rather than
my comments
(I didn't expect such strong responses btw!)
You are proposing the removal of a general, orthogonal feature (and breaking
code in consequence!) just because of a new syntax for a single special case of
that feature. That is quite simply ridiculous.
Ok, I may have come across a little strongly (was very tired) - I'm not
_actually_ saying we should remove it, I'm just pointing out why
adding .clear() to lists seems to be unnecessary and slightly messy. The
suggested removal of assignments to slices is a theoretical statement.
.clear() would be non-orthogonal syntactic sugar. That's okay! Python has
syntactic sugar in a number of other places, too! Appropriate doses of syntactic
sugar and non-orthogonality are precisely what lets you implement "There should
be one-- and preferably only one --obvious way to do it." The really key word in
that sentence is "obvious", not "one".
FWIW, removing slice assignment would be a gross form of non-orthogonality, too.
__getitem__, __setitem__ and __delitem__ should all be able to accept the same
indices (or else raise exceptions in the case of immutability).
hummm - I'm sure it would be confusing behaviour if it was not
available, but I'm not sure how it would be non-orthogonal
>>> l = range(10)
>>> l[3:7] = range(4)
>>> l
[0, 1, 2, 0, 1, 2, 3, 7, 8, 9]
How do you want to do that with clear?
That l[:] = [] clears a list is more of an "accident" than the intent of
slice-assignment. Removing it in favor of clear() would remove an
orthogonal feature of updating parts of a list with another iterable.
Diez
--
http://mail.python.org/mailman/listinfo/python-list
