ANN: set-0.2 module available

[Roman Suzi]

On Tue, 21 May 2002, Aric Coady wrote:

>On Tuesday, May 21, 2002, at 03:15 AM, Denis S. Otkidach wrote:
>> Here is another problem:
>>>>> from set import set
>>>>> s=set((1,3,5))
>>>>> hash(s)
>> 1272199707
>>>>> s&=set((2,4,6))
>> Traceback (most recent call last):
>>   File "<stdin>", line 1, in ?
>> TypeError: set has become immutable
>>
>> If the set became immutable it should not be modified in-place,
>> but &= operator should create new object according to ?=
>> documentation.  Unfortunately, it makes this error prone "2 in 1"
>> solution even more hard to debug.
>
>I agree that's unfortunate, but I like the alternative even less.  

I think the above behaviour is not acceptable for fundamental type,
because it changes state implicitely. Those who want sets to be keys must
explicitly tell so by converting (copying) set to tuple (for example).

>To me, the fact that it will raise an error if you inadvertently use a
>set as if it's both mutable and hashable is precisely the reason why
>it's an acceptable compromise to let it act as either mutable or
>hashable.

IMHO, it is not acceptable. One of the characteristics of user-friendly
system is not to change state implicitely. It could nightmare if for
example "print" behaved differently in for-loops. This approach invites
subtle errors and gives nothing worth in return.

>If I had to give up those immutable errors, I'd rather just choose one 
>(mutable) to be the default and force those who want it to be hashable 
>to choose that explicitly.

Yes. And better - outside set type.

Set is a container type and as such it's first goal is to bring set
behaviour to Python. Other goals (to be used as key, etc) are secondary
and solvable by means other than implicite loss of mutability. IMHO.

Sincerely yours, Roman Suzi
-- 
\_ Russia \_ Karelia \_ Petrozavodsk \_ rnd at onego.ru \_
\_ Wednesday, May 22, 2002 \_ Powered by Linux RedHat 7.2 \_
\_ "I'd give my right arm to be ambidextrous." \_