Suggestion: make sequence and map interfaces more similar

[Marco Sulla]

On 30 March 2016 at 02:55, Terry Reedy <tjreedy at 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 <tjreedy at 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.python at 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 <steve at 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.