Re: [Python-ideas] unify usage of mutable and immutable objects
To me, 'pop' implies mutation. Tuples do not have a pop method, and it is not obvious to me that either tuples or frozensets should. What are > the use cases that are not better served by converting to list or set? -- Terry Jan Reedy
1) coverting to set or list is O(n) in time 2) if I have to keep the old copy, standard set solution will be O(n) both in time and space! 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.
On Tue, Feb 28, 2017 at 2:57 PM, 语言破碎处 <mlet_it_bew@126.com> 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.
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. At 2017-03-01 07:14:33, "David Mertz" <mertz@gnosis.cx> wrote: On Tue, Feb 28, 2017 at 2:57 PM, 语言破碎处 <mlet_it_bew@126.com> 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.
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...@gnosis.cx <javascript:>> wrote:
On Tue, Feb 28, 2017 at 2:57 PM, 语言破碎处 <mlet_...@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.
participants (3)
-
David Mertz -
Neil Girdhar -
语言破碎处