On Tue, Jun 30, 2020 at 10:18:34AM +0100, Stestagg wrote:
> This property is nice, as .keys() (for example) can operate like a set and
> give lots of convenience features. However this doesn't really mean that
> these objects are trying to *be* sets in any meaning way,
Please read the PEP:
https://www.python.org/dev/peps/pep-3106/
It was an explicit design choice to make them be set-like, not an
accident. The whole point was to offer a set interface.
I'm pretty familiar with that pep, I'm not sure how knowledge of its contents affects this idea/discussion in any material way.
> Plus, the following example shows how quickly the set emulation falls-down:
>
> py> set({'a': [1]}.items())
> Traceback (most recent call last):
> File "<stdin>", line 1, in <module>
> TypeError: unhashable type: 'list'
They aren't small-s sets, the concrete set class. But they are large-s
Sets, the ABC. They provide the same set interface without needing
elements to be hashable.
Right, as demonstrated in my example.
The point being made, was that the utility of trying to shoehorn the dict_* types into a Set pidgeon-hole is quite limited, as practicalities get in the way.
> I don't think inventing new methods for emulating __getitem__ is that
> useful here, there is a well established standard for getting items from a
> container by index, I think we should use it :).
We can't use dict[index] because the index can also be a key:
d = {'a': None, 'b': None, 0: 999}
d[0] # return 'a' or 999?
The currently discussed option is for adding`__getitem__` to the dict_keys/dict_items/dict_values types, *NOT* the base `dict` type.
So one way or another we have to invent a new standard for getting items
by index position. Dict views are not containers, they are *views*, so
it makes just as much sense (maybe more) to add a method on the dict
itself to return the nth key as to pretend that set-like views are
sequences.
> Here's my understanding of the performance implications of allowing
> __getitem__ on dictview objects:
[...]
> However, split dicts are *not* really relevant here, because typically
> dicts in use aren't split() (for example mutating a split dict) returns a
> traditional' dict.
Doesn't matter whether they are "typically" used or not, the same API
must work regardless of whether the dict is a split dict or traditional
dict.
If you read the OP again you'll see that indexing the views of split dicts is trivially doable in O(1) time. My point about the "typical" usage, is that having a variant that's O(1) is not material to the performance concerns, because in most cases, an O(n) version will have to be used.
The point wasn't that: "It's atypical so we can ignore it", but rather: "It's faster/better, but seldom available to be used, here's how we do it for the more common case..."
--
Steven
_______________________________________________
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-leave@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at https://mail.python.org/archives/list/python-ideas@python.org/message/ZLAJXSJNPP4RIU2MFRPISVS2RRETX3QQ/
Code of Conduct: http://python.org/psf/codeofconduct/