Interface of the set classes
Pierre Barbier de Reuille
pierre.barbier at cirad.fr
Fri Oct 29 16:20:39 CEST 2004
Alex Martelli a écrit :
> Pierre Barbier de Reuille <pierre.barbier at cirad.fr> wrote:
>>Ok, I first want to stress that I looked through the newsgroups archives
>>(on Google) for an answer to my question, but I didn't find it.
>>It's about the interface of the set classes as defined in the PEP 218.
> You should check out the built-in set type in 2.4 (the beta is quite
> usable, go ahead and get it!) -- dunno if PEP 218 has been updated to
> reflect exactly what's ended up in the language.
I've read somehow the documentation, and that's exactly what's in the PEP :)
>>I don't understand why the sets has an interface of mapping object
>>without associated value and not an interface of sequence ?
> Sequences have order, sets don't.
Yes, and ? I don't understand why that's a reason ? If you take the C++
STL, the sets implements the sequence concept but without the impossible
things to do ... so if you don't need the order in your list you can
switch freely from vector to list to sets depending on the properties or
efficiency you want. I don't know why this is different in Python !
Using "add" instead of "append" and "update" instead of "extend" does
not makes sense to me. It's even worse because Python rely more on
interface than in inheritence ... so making classes similar helps a lot
>>Then, why can't you at all access sets element by position ? As Python
>>iterator are so poor (mainly, you cannot copy them ...) you have things
> That's what itertools.tee is for (in Python 2.4).
Oky, thanks ^_^ So I should not need the __getitem__ anymore in sets.
>>you cannot do without positionnal iteration (typically when you need to
>>store the current position and go on the iteration to restart from the
>>saved position later on).
> Yep, the quintessential usecase of itertools.tee.
>>Please, if this discussion already exists give me the pointer ... and
>>don't tell me "because of implementation if over dictionnary" ... I
>>don't think that can be a good answer :o)
> It would be false (in 2.4) -- set is a builtin type, side by side with
> list and dict, not relying on either of them.
Yes, I know it will become a built-ins type ! But that does not explain
this interface incompatible with lists. I would expect maximum
compatibility to be able to exchange the types. Even compatibility
between dictionnary and list is usefull ... because at some point you
can consider a dictionnary as a list of tuples. And then, too bad you
cannot because of simple design decisions.
> It may well be that, for whatever needs, you need a different container
> type. That's what the collections module in the standard library is for
> (again, in 2.4) -- in 2.4 there's only deque in it, but that's the place
> where, in 2.5, other collection types may go. In my case, the main
> reason I find myself using something other than set, for example, is
> when I have non-hashable items.
> The best way to get new collection types into Python 2.5 is to write
> them now (pure Python, pyrex, C, whatever), publish them (Activestate
> cookbook, sourceforge, whatever), get a user-base so that experience can
> enhance them, _and_ also get involved in python-dev to make a PEP and
> champion it. No hurry, it's probably 18+ months to go to 2.5, but the
> herein-suggested, soundest process to make it likely that one's changes,
> in the best possible form, will get into 2.5's standard library, does
> take its time, too;-)
No, what I want is not a new container type. I just want to be able to
change the container I use without changing all my codes ! It's too
expensive. At the end, I finish using sets and hashsets from the STL
exported to Python as sequences. The efficiency is the same and it just
works great :) I just feel bad not using the "standard" sets class ...
More information about the Python-list