On 30 March 2016 at 02:55, Terry Reedy <tjre...@udel.edu> wrote: > To me [seq.items() and seq.keys()] are useless and confusing duplications > since enumerate()(seq) > and range(len(seq)) are quite different from dict.items and dict.keys.
It's true. Indeed IMHO it's enumerate() that will be a confusing duplication. On 30 March 2016 at 02:55, Terry Reedy <tjre...@udel.edu> wrote: > At least in CPython, changing a dict disables view iterators. OrderedDict does not. On 30 March 2016 at 07:43, Steven D'Aprano <steve+comp.lang.pyt...@pearwood.info> wrote: > This is not an argument about dicts being mutable, because clearly they > aren't. This is an argument about key:value pairs being stable. So you basically say "I expect to get the value x from key y". Let me apply your point of view to lists. In lists, I expect to get the value x from index y. If I insert an item in a position before index y, I expect to get x at index y+1. But what if I write a class with a method insertPlus() that sets None at y+1 and x at y+2? I can say it does not violate the list contract, since you're extending the base class and implementing a new method that is not present in base class. If you extend a dict to act as a list, you're only adding *constraints* to existing methods and adding new methods. You're not completely change the existing ones, so the implementation is perfectly valid. Finally, let me quote the official docs: A mapping object maps hashable values to arbitrary objects [...] A dictionary’s keys are almost arbitrary values [...] https://docs.python.org/3/library/stdtypes.html#dict Mapping:A container object that supports arbitrary key lookups https://docs.python.org/3/glossary.html#term-mapping A sequence satisfies all these requirements, with the only exception that keys are not arbitrary. But no one will tell you that a child class that make a *restriction* over the original one will break rules. On 30 March 2016 at 17:56, Steven D'Aprano <st...@pearwood.info> wrote: > If the OP wants to create his own "StrangeDict", which he himself described > as "terrible", then he can do so. But to make all dicts and lists behave in > this "terrible" and "strange" way is a terrible idea. You did not understand well what I mean, my dear friend. I applied the word "terrible" to my code, not to the concept. You've demonstrated that a fair thinker, so do not fall in the temptation to play with words. -- https://mail.python.org/mailman/listinfo/python-list
