dict.keys() and dict.values() are always the same order, is it?

[John Yeung]

alex23 wrote:
> > > > I stand corrected. Thanks Cameron.

Cameron Simpson wrote:
> > > Oh, I was all ready to say what you said, but decided
> > > to check the docs myself first:-)

John Yeung wrote:
> > I am not too comfortable relying on it.  It feels
> > fragile and "implementationy" to me, as I'm sure
> > it does to many people (such as everyone in this
> > thread so far! ;)

Steven D'Aprano wrote:
> It is a language feature that is guaranteed to be true
> for every implementation of Python

I never said it wasn't guaranteed to be true.  I said it *feels*
implementationy *to me*.

> Defensive programming is good, but at the point that you
> don't believe the promises that the language makes, how
> can you trust anything?

[Leave it to me to answer a rhetorical question.]  I *believe* all the
promises a language makes.  I don't *trust* (more like depend on) all
of them equally.  If I (that is, me personally, with all my
fallibility, insufficient knowledge of the language, etc.) feel that a
promise is one that the language absolutely cannot afford to break, I
will trust it not to break that promise.  I won't need some document
telling me "no, really and truly, we guarantee that".  Other promises
seem (to limited, fallible, subjective me) as though they would not be
the end of the world if the language broke them.  And so I am less
likely to rely on those promises, even as I steadfastly stake my life
on other promises.

> if you don't trust the language to behave
> correctly in this case:
>
> pairs = zip(d.values(), d.items())
>
> what makes you think you can trust d.iteritems(),
> list comprehensions, or even tuple packing and unpacking?

Not sure how often I'd want a list of value-item pairs, but anyway,
you don't have to trust that d.values() and d.items() have the same
order to use them individually, or to use the other stuff.  I do trust
that list comps work and that tuple packing and unpacking work.  And I
trust each individual key-value pair in a dictionary to have the
correct key associated with the correct value... because that is the
whole purpose of the dictionary.  Without it, dictionaries are just
useless.  But d.items(), d.keys(), and d.values() could all use
different orderings without rendering dictionaries (or zip) pointless,
and certainly without destroying the usefulness of the language.

> It would be a waste of time and code for me to write
>
> a//b, a%b
>
> just because I can't remember what divmod() does.

That is your opinion, and it may well be the opinion of the Python
community at large.  Fine.  The version that doesn't use divmod is, to
me, short enough and easy enough to read.  I can easily imagine
someone spending enough time looking up the docs (even if only to type
help(divmod)) that it would be a net gain of time to simply avoid
divmod altogether and just type the code that comes naturally to them.

> > All in all, the alternative idiom for flipping keys
> > and values (provided in the docs a couple of sentences
> > down from your quote) is short enough for my taste,
> > easy enough for me to read, and never makes me wonder
> > if I should check the docs just to be sure:
>
> >   pairs = [(v, k) for (k, v) in d.iteritems()]
>
> Yes, and if you can't remember whether or not ints are
> automatically promoted to longs, you will continue writing
> this long after it became unnecessary:
>
> try:
>     result = a + b
> except OverflowError:
>     result = long(a) + long(b)
>
> and then other coders will laugh at you :)

Well, maybe there are coders out there who find that snippet short
enough and easy enough to read.  Maybe they are comfortable typing it
all the time and seeing it all over their code.  But if *I* can't
remember whether ints are automatically promoted to longs, then what
*I* will continue to write is actually just

result = long(a) + long(b)

;)

John