Suggestion: make sequence and map interfaces more similar

[Marco Sulla]

On 29 March 2016 at 16:31, Chris Angelico <rosuav at gmail.com> wrote:
> But the definition of a sequence, and likewise the definition of a
> mapping, goes deeper than that. A sequence has *relative* stability;
> if one item is at a lower index than another, it will continue to be
> at a lower index, until you change one of those two items. Changes
> elsewhere in the sequence might bring them closer together or push
> them further apart, but one of them is still earlier in the sequence
> than the other. A mapping, on the other hand, has *absolute*
> stability. Any given key->value relationship is stable in and of
> itself. If you stuff a thing into a dict under a particular key, you
> expect to be able to get it back using that key, not some other.

It's the same arguments of Steven D'Aprano. Let me counter these
arguments with this example:

>>> class StrangeDict(dict):
...     def insert(self, k, v):
...         if k in self:
...             for key in [x for x in sorted(self.keys()) if x >= k]:
...                 v_next = self[key]
...                 self[key] = v
...                 v = v_next
...
...             self[key+1] = v
...
>>> a = StrangeDict({0:5, 1:7, 2: 14})
>>> a.insert(1, 5)
>>> a
{0: 5, 1: 5, 2: 7, 3: 14}

Yes, it's a terrible class and lacks a lot of safety checks, but I
don't think at all it violates the map contract. You can continue and
add some constraint at __init__() about key types and their
contiguity, some other methods and voila', you'll get a list-like
class.

Let me add that an items() and keys() for sequences will be also
useful for day-by-day programming, since they will be a shortcut for
enumerate(seq) and range(len(seq))

> The whole idea of making sequences and mappings more similar is highly
> distasteful to me, and I've figured out why. It's the exact problem
> with the PHP array - it's not sure whether to act as a mapping or a
> sequence

This is a good point. This is not true for mutable sequences (lists),
since they will have a lot of methods (append, pop etc) that allows
you to distinguish them, but immutable sequences like tuples will be
not easily distinguishable using duck typing.

I think the main problem is in __getitem__. __getitem__ can be used as
slice method checking if its parameter is a slice. If the slice method
was a separated method, this problem will not arise.


On 27 March 2016 at 21:24, Mark Lawrence <breamoreboy at yahoo.co.uk> wrote:
> Why do you need a new interace if all you're trying to do is create a
> vdict class that has "iter(d) == iter(d.values()), and should also
> have a count() method, like sequence types"?

Since simply adding get(), items(), keys(), values() to existing
sequence interface will likely break existing code, I would try also
to write new sequence types, using a common interface with maps. This
is my idea.