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 -- http://mail.python.org/mailman/listinfo/python-list