Path: csiph.com!fu-berlin.de!uni-berlin.de!not-for-mail
From: Marco Sulla <mail.python.org@marco.sulla.e4ward.com>
Newsgroups: comp.lang.python
Subject: Re: Suggestion: make sequence and map interfaces more similar
Date: Wed, 30 Mar 2016 21:35:59 +0200
Lines: 59
Sender: forwardedby@e4ward.com
Message-ID: <mailman.224.1459366624.28225.python-list@python.org>
References: <CABbU2U_DsSC=6d0HOwgGnzQZ0=r6U2sf_zOJP0U_w7_i0RrOKQ@mail.gmail.com> <mailman.92.1459101740.28225.python-list@python.org> <56f8836b$0$1602$c3e8da3$5496439d@news.astraweb.com> <56FA8C71.4050306@rece.vub.ac.be> <CAPTjJmqjgnDvzS7=_YRf+T78GYz7J26FzWGfwrygYLeq2E9FeA@mail.gmail.com> <CABbU2U9m-35UqK5KqRj7Y_oLdq_dgH3_EScLb4Sf3UNB4oCgmQ@mail.gmail.com> <CAPTjJmp1x-5=gEwBB=n-kt6YeVd6OiN_BGh5tNoL7UPYNqKb8w@mail.gmail.com> <mailman.176.1459309120.28225.python-list@python.org> <56fb677f$0$11121$c3e8da3@news.astraweb.com> <lf5twjoo2w8.fsf@ling.helsinki.fi> <56fba7d3$0$1616$c3e8da3$5496439d@news.astraweb.com> <lf5h9fouumu.fsf@ling.helsinki.fi> <56fbc518$0$1593$c3e8da3$5496439d@news.astraweb.com> <mailman.203.1459343574.28225.python-list@python.org> <56fbf73d$0$1591$c3e8da3$5496439d@news.astraweb.com>
Reply-To: mail.python.org@marco.sulla.e4ward.com
Mime-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
In-Reply-To: <56fbf73d$0$1591$c3e8da3$5496439d@news.astraweb.com>
Precedence: list
Xref: csiph.com comp.lang.python:106109

On 30 March 2016 at 02:55, Terry Reedy <tjreedy@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 duplicatio=
n.


On 30 March 2016 at 02:55, Terry Reedy <tjreedy@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@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=E2=80=99s 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@pearwood.info> wrote:
> If the OP wants to create his own "StrangeDict", which he himself describ=
ed
> 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.