On Wed, Jul 1, 2020 at 12:18 PM Steven D'Aprano <[email protected]> wrote:
> 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 -- [email protected] > To unsubscribe send an email to [email protected] > https://mail.python.org/mailman3/lists/python-ideas.python.org/ > Message archived at > https://mail.python.org/archives/list/[email protected]/message/ZLAJXSJNPP4RIU2MFRPISVS2RRETX3QQ/ > Code of Conduct: http://python.org/psf/codeofconduct/ >
_______________________________________________ Python-ideas mailing list -- [email protected] To unsubscribe send an email to [email protected] https://mail.python.org/mailman3/lists/python-ideas.python.org/ Message archived at https://mail.python.org/archives/list/[email protected]/message/I3IFDGXWAXT5EIOXN3DZDIB2Q56ZX2BX/ Code of Conduct: http://python.org/psf/codeofconduct/
