Bryan Olson wrote:
> Magnus Lycka wrote:
>> Do you really have a usecase for this? It seems to me that your
>> argument is pretty hollow.
>
> Sure:
>
> if item_triggering_end in collection:
> handle_end(whatever)
> collection.clear()
>
> Or maybe moving everything from several collections into
> a single union:
>
> big_union = set()
> for collection in some_iter:
> big_union.update(t)
> collection.clear()
I don't understand the second one. Where did 't' come from?
Anyway, tiny code snippets are hardly usecases. Are these from
real code? If they are, why aren't there support for emptying
lists? Have you patched your Python? Didn't you actually need
to support lists?
I still don't see any convincing usecase for the kind of
ducktyping you imply. There are certainly situations where
people have used lists or dicts before there were sets in
Python, and want to support both variants for a while at least,
but since their APIs are so differnt for these types, .clear()
seems like a non-issue.
If this was a problem in the real world, I bet we'd see a lot
of code with functions similar to this:
def clear(container):
try:
del container[:]
except TypeError:
container.clear()
If you *do* have this problem, this is a very simple workaround.
>> As far as I understand, the only operation which is currently used
>> by all three collections is .pop, but that takes a different number
>> or parameters, since these collections are conceptually different!
>
> The all support len, iteration, and membership test.
Ok. Forgot that. id(), str() and repr() as well. Still, after almost
10 years of Python programming I can't remember that I ever ran into
a situation where I ever needed one single piece of code to empty
an arbitrary container. It's trivial to solve, so I wouldn't have
stopped to think about it for even a minute if it happened, but I
still don't think it happened.This was never a problem for me, and
I don't think I saw anyone else complain about it either, and I've
seen plenty of complaints! ;)
I can understand the argument about making it easy to remember how
to perform an action. I think the current situation is correct. To
introduce redunancy in this case (del x[:] <==> x.clear()) would not
be an improvement of Python. In the long run, such a strategy of
synonyms would make Python much more like Perl, and we don't want
that. So I can understand that the question pops up though (but
not why it gets such proportions).
I don't buy this duck-typing argument though. Considering how little
it would change in unifying these divergent APIs, it still sounds
as hollow to me.
> Many algorithms make sense for either sets or lists. Even if they
> cannot work on every type of collection, that's no reason not
> to help them be as general as logic allows.
>>> class BryansList(list):
... add=list.append
... def clear(self):
... del self[:]
...
>>> b = BryansList([1,2,3,4,5])
>>> b
[1, 2, 3, 4, 5]
>>> b.add(6)
>>> b.clear()
>>> b
[]
Happy now? You can keep it, I don't need it. :)
Most of us consider minimal interfaces a virtue.
--
http://mail.python.org/mailman/listinfo/python-list
