Re: list.clear() missing?!?

On Tue, 11 Apr 2006 14:49:04 -0700, Ville Vainio wrote:

John Salerno wrote:

Thanks guys, your explanations are really helpful. I think what had me
confused at first was my understanding of what L[:] does on either side
of the assignment operator. On the left, it just chooses those elements
and edits them in place; on the right, it makes a copy of that list,
right? (Which I guess is still more or less *doing* the same thing, just
for different purposes)

Interestingly, if it was just a "clear" method nobody would be confused.

Even more importantly, you could say help(list.clear) and learn something
useful, instead of trying help(del) and getting a syntax error.

help(del)
File "<stdin>", line 1
help(del)
^
SyntaxError: invalid syntax

I know Python isn't a purely OOP language, but in my opinion using
statements like del should be avoided when there is an easy and natural OO
way of doing it. Something like name.del() which means "delete the
reference to name in name's namespace" feels wrong, and may not even be
possible with Python's object model, so del name is a natural way to do
it.

But name.clear() meaning "mutate the object referenced by name to the
empty state" is a very natural candidate for a method, and I don't
understand why lists shouldn't have it.

For lists, it would be natural to have a hypothetical clear() method
accept an index or slice as an argument, so that these are equivalent:

del L[:] <=> L.clear()
del L[n] <=> L.clear(n)
del L[a:b] <=> L.clear(slice(a, b))


# untested reference implementation:
class ClearableList(list):
def clear(self, obj=None):
if obj is None:
obj = slice(0, len(self))
if isinstance(obj, int):
self.__delitem__(obj)
elif isinstance(obj, slice):
self.__delslice__(obj.start, obj.stop)
else:
raise TypeError


--
Steven.

.

Relevant Pages

  • Re: Cons cell archaic!?
    ... How would the implementation of a Lisp without a using cons look like? ... the irregularity in its often cited regular syntax. ... Lisp at core is based on functional programing on lists. ...
    (comp.lang.lisp)
  • Re: Cons cell archaic!?
    ... fundamental problems of lisp. ... lists and arbitrary binary trees, and it can be used to emulate ... One is the irregularity in its often cited regular syntax. ...
    (comp.lang.lisp)
  • Re: Maintain list of attached event handlers (.Net 1.1)
    ... Your requirement to unsubscribe when the event fires is completely independent of how you unsubscribe other events later. ... A basic rule of event management is that when you subscribe the first handler, the reference to the event has to be instantiated. ... While you didn't actually post any code that showed such an enumeration, I will take as granted that somewhere you actually do. ... It's simple, it works, and is MORE performant than trying to maintain a list or lists or other data structures as various events are raised and unsubscribed from. ...
    (microsoft.public.dotnet.framework)
  • Re: Other notes
    ... For unary the normal funsyntax is good enough, ... that suggestion of mine cannot solve new kinds ... a function to a list) and the flattening of a list.< ... And like in the indexing of lists: ...
    (comp.lang.python)
  • Re: Do people dislike parentheses or the conceptual mismatch with trees?
    ... Lisp syntax, ... you don't understand syntax in Lisp. ... symbols with packages, circular lists, arrays ... READ takes an external representation and internalizes it ...
    (comp.lang.lisp)