Interface of the set classes

[Pierre Barbier de Reuille]

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 
reusability.

> 
> 
>>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;-)
> 
> 
> Alex

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 ...

Pierre