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.
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. An analogy for you to think about: both floats and complex numbers are numbers. But: py> from numbers import Number py> isinstance(1.5, Number) and isinstance(1.5j, Number) True py> float(1.5j) Traceback (most recent call last): File "<stdin>", line 1, in <module> TypeError: can't convert complex to float I trust you aren't going to argue that one or the other of floats or complex numbers aren't numbers.
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? 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. -- Steven