Dictionary from list?

[Terry Reedy]

"Tim Peters" <tim.one at home.com> wrote in message
news:mailman.1004203049.21483.python-list at python.org...
> [Terry Reedy]
> > Fact: a Python dictionary literal is a sequence of key:value pairs
of
> > literals, with the first becoming a hashable object, and only such
a
> > sequence.
>
> Sounds more like a definition than a fact <wink>.

You've touched on a subtle difference of role-related viewpoints
<return wink>.  Implemented definitions create observable facts.  For
you as a core coder, the above *is* a definition (mandated by your
partner and bought into by you) to be maintained as you revise the
code.  For me as a user, it is a current observable fact which I
cannot change.  For me as an advocate/supporter of the idea that the
behaviour of dictionary() with respect to sequences should parallel
that defined fact, the rhetorical point is that it is not merely 'a'
definition found in a book on some shelf but 'the' intended and
observed behavior that we users are currently familiar with and
hopefully comfortable with.

>>...
> > Proposed rule 1: the dictionary() constructor should accept a
sequence
> > of pairs of objects, with the first being keyable (hashable).  In
> > particular, it should invert dict.items.
>
> In current CVS, it does.  In 2.2-speak, it accepts an iterable
object
> producing iterable objects producing exactly 2 objects.

To me, 'exactly 2' implies that dictionary() calls pair.next() a third
time and objects if it succeeds (as I believe it should, see below).
Presently true?

> > Note: by type, 'pair' might mean duple only; by interface, it
would
> > mean an object reporting a length of two and yielding objects with
> > indexes 0 and 1.
>
> "By interface" is important, but the details there are off for
2.2 --
> iterable objects don't have to support len or indexing.

Whoops.  I didn't recurse on the generalization from fixed sequence to
iterator.  But there is a point to the 'length of two' bit (again, see
below).

>  For example,
>
>     class AddressBookEntry:
>         # with .firstname, .lastname attributes
>         ...
>         def __iter__(self):
>             return iter((self.firstname, self.lastname))
>
> A sequence of AddressBookEntry instances is OK to pass to
dictionary(),
> despite that an AddressBookEntry defines neither __len__ nor
__getitem__.  A
> generator yielding instances of AddressBookEntry is also fine; etc.

Here's the 'below' twice referred to above:  Would AddressBookEntry
instances still be OK if the last line were, for instance, changed to

             return iter((self.firstname, self.lastname,
self.address))

My point about a length of exactly two is a) the observation that
silently ignoring items beyond two is not consistent with the
processing of literals ('d={1:2:3}', for example, is a SyntaxError)
and b) my feeling that doing so would as often be wrong, creating a
silent bug, as right.

> > Comment: once pair is defined, this rule gives a uniform target
for
> > conversion from other formats, including those generated by other
> > software systems.  I currently vote for the latter.
>
> I didn't understand "the latter" here, unless it's a vote for "other
> software systems", in which case I'm keen to see the patch <wink>.

Whoops again, this time in respect to wording.  I was referring to a
broad interface definition of 'pair' (versus a narrow structural
definition).  Since you have already implemented such, no patch is
needed.

My main point is that clearly defining the sequence part of the domain
of dictionary() and doing so by analogy with the domain of the literal
constructor gives a clear target for conversion programs from the
potentially unbounded set of other forms that which you and I seem to
agree should remain outside that domain.

> > Proposed rule 2: dictionary() should reject any other sequence,
just
> > as does the internal constructor-from-literals.
>
> "Sequence" is a slippery word.  dictionary() continues to accept a
mapping
> object too.  Of course, "mapping object" is also a slippery phrase.

I am only discussing dictionary(<sequence>) and have no opinions about
dictionary(<mapping>), nor information on what the alternatives might
be.

> > Paraphrase: conversions from the many other possible formats
should be
> > handled externally from dictionary().
>
> Indeed, we're going to cheerfully endure abuse for sticking to that.

Relative to the alternative, so will I for advocating such.

> > Opinion 3: Given the fact and comments above, these two rules
should
> > be easy to understand and teach.
>
> Yup.

Glad we agree ;<)

Terry J. Reedy