On 30/06/2020 18:31, Christopher Barker wrote:
> The first improvement on that was the iter* methods, and then (inspired by
> JAVA) it was determined that we could have view objects that could provide
> efficient iterators, and also set-like behavior. But I don't see any
> comments in the PEP about why indexing was rejected, but it's implicit in
> the fact that dicts were explicitly unordered at the time that PEP was
I'm sorry, I don't think that logic holds water. Dicts at the time were
explicitly unordered (and I still mostly find it more useful to think of
them as unordered), but iterators are explicitly ordered. You probably
couldn't rely on that order being consistent if you fiddled with the
dict between iterations, but that's not behaviour we encourage with
Don't get me wrong, if it's not going to cause performance issues I
think being able to index views would be great, but I don't think this
is the right way to justify it.
I wasn't justifying it -- I was simply saying that no one ever specifically decided that we DIDN'T want to be able to index dict views -- when they were created, it simply wasn't an option. Now it is, so we need to rethink it.
> if it's not going to cause performance issues
I can't see how it could possibly *cause* performance issues. It isn't as great performance as we would like, but I think it's still as good, and probably much better, than any other way to accomplish the same thing.
Even if the performance were bad, I don't think we'd be handing out a foot gun here: who's going to write:
when they know what the key is for the nth item?
Other than the usual "more code to write and maintain", I still don't see a downside.
If anyone who knows could comment on the feasibility, that would be
great too :-)
Rhodri James *-* Kynesim Ltd
Python-ideas mailing list -- email@example.com
To unsubscribe send an email to firstname.lastname@example.org
Message archived at https://email@example.com/message/5ZZ2MNP3YEJDXBCSJVTPJN4KTA64HKAO/
Code of Conduct: http://python.org/psf/codeofconduct/