[Python-ideas] unify usage of mutable and immutable objects

[Neil Girdhar]

On Tuesday, February 28, 2017 at 6:48:42 PM UTC-5, 语言破碎处 wrote:
>
> > A hypothetical frozenset.pop() is also necessarily O(N).  It needs to 
> copy N-1 elements into the new (smaller) frozenset object.  So this isn't 
> an argument.
> Pop tuple/frozenset(standard one) gain no benefit. # O(n)
> It is a different story for balanced tree. # O(log n)
>
> > Sounds like `collections.deque` might be what you want (for concurrency, 
> not for immutability).  But a local copy will require, by definition, a 
> *copy* operation either way.
> My intent is to unify "SET" interface, not for to using deque.
>      I want something that is SET can use anywhere regardless mutable or 
> not.
>     And the idiom SHOULD work for other type.
>
> WHY set.add / list.sort return None?
>      if return self,  someone may think it don't modify the orignal object.
>      so, mutable object will have different methods.
> Such differences are good UNLESS we want to ignore it explictly.
> We need a uniform way to make a interface suitable for both cases. 
>
>
collections.abc.Set is the uniform interface suitable for mutable and 
immutable sets:

https://docs.python.org/3/library/collections.abc.html

It contains:

__contains__, __iter__, __len__ __le__, __lt__, __eq__, __ne__, __gt__, 
__ge__, __and__, __or__, __sub__, __xor__, and isdisjoint

Is there something missing?  I don't think add should be there. I think if 
you want to start mutating a (possibly immutable)  set, you should convert 
it to set (pay the linear cost up-front) and then start mutating it.


>
> At 2017-03-01 07:14:33, "David Mertz" <me... at gnosis.cx <javascript:>> 
> wrote:
>
> On Tue, Feb 28, 2017 at 2:57 PM, 语言破碎处 <mlet_... at 126.com <javascript:>> 
> wrote:
>
>> 1) coverting to set or list is O(n) in time
>>
>
> A hypothetical frozenset.pop() is also necessarily O(N).  It needs to copy 
> N-1 elements into the new (smaller) frozenset object.  So this isn't an 
> argument.
>  
>
>> 2) if I have to keep the old copy,
>>     standard set solution will be O(n) both in time and space!
>>
>
> Again, nothing gained here. Same applies to frozenset.pop() (assuming it 
> returns both the item popped and a reduced set).  If you just want 
> "something from frozenset" without creating a new almost-copy frozenset, 
> that is spelled `next(iter(fs))`.
>  
>
>> working examples:
>>     1) priority queue:
>>         insert and pop occur
>>     2) share immutable data to difference subroutines:
>>         each one can modify local copy safely and concurrency.
>>
>
> Sounds like `collections.deque` might be what you want (for concurrency, 
> not for immutability).  But a local copy will require, by definition, a 
> *copy* operation either way. 
>
>
> -- 
> Keeping medicines from the bloodstreams of the sick; food 
> from the bellies of the hungry; books from the hands of the 
> uneducated; technology from the underdeveloped; and putting 
> advocates of freedom in prisons.  Intellectual property is
> to the 21st century what the slave trade was to the 16th.
>
>
>
>  
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-ideas/attachments/20170331/620028c5/attachment-0001.html>