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 _______________________________________________ Python-ideas mailing list -- python-ideas@python.org To unsubscribe send an email to python-ideas-le...@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/
