On Fri, Jul 10, 2020 at 06:06:03PM +0100, Stestagg wrote:
I don't believe that this feature would steepen the language learning curve however, but actually help to shallow it slightly (Explained more below)
It steepens it because it's yet another feature to learn. Is it dicts or dict views that supports indexing? What's the difference between dict[1] and dict.keys()[1]? These things need to be taught. Remember that there is a cohort of Python programmers who have never, ever been exposed to any version of Python where dict.keys returned a list. They do not have your expectation "but it used to work!". And that cohort is only going to increase.
What making dict_* types a Sequence will do is make this code (as written) behave: 1. like it used to do 2. like most people seem to expect it to.
The "used to" part is easy to fix: call list. That's what dict.items etc used to implicitly do. Now it's explicit. As for the second part, I agree -- I was surprised that it didn't work, but I fear that's because numpy is, in many places, awfully un-Pythonic. numpy's design seems to me to be more closely inspired by a hodge-podge of mismatched Fortran and C libraries than Python, which is hardly surprising.
Currently numpy does something that I consider unexpected (I'm sure, given your previous responses, you'd disagree with this,
Heh, no, I consider numpy to be doing the wrong thing here. I think this exposes numpy's pre-iterator origins: >>> np.array(iter([1, 2, 3, 4])) array(<list_iterator object at 0x7f3d7d0e1be0>, dtype=object) but I'm sure that numpy fans will argue that's a good thing, if you want to pass an iterator to array, explicitly converting it to a sequence is the right thing to do. [...]
I suspect that even if dict items were indexable, Raymond Hettinger would not be happy with random.sample on dict views.
I don't know why? I can understand deprecating sets here as they're unordered, so the results when seed() has been called are not consistent. I don't see why Raymond would object to allowing sampling an ordered container, one from which the results will be reproducible.
I wish to back away from predicting what Raymond would say. When I wrote that in the wee hours of the morning (local time) it seemed perfectly obvious to me why he would dislike it, but after a good sleep I now find myself completely unable to recall why that was the case. So let me backpedal furiously, withdraw that remark, and let Raymond speak for himself :-) [...]
This is the proposal, I want to make these things Sequences.
But they can't be Sequences, since they are already Sets. They would have to be a hybrid of the two, and that, I feel, comes with more baggage than just being one or the other. It's not that I react to the very idea with horror, but it's not a clean design to mix Sequence and Set (OrderedSet?) so without a good reason for it, I'd rather hold off. Not so much "Never!!!" as "Not yet." Besides: - to make views a Sequence, they would have to also support count and index methods, so this proposal doesn't go far enough; - and in Python 2, they weren't merely Sequences, they were full-blown actual lists, which supported slicing, in-place sorting, and various other methods. So this proposal doesn't come close to either returning to the Python 2 days or offering a Sequence API. It's just a hybrid that falls short of being either a sequence or a list.
...not that we can jump to the 350th key without stepping through the previous 349 keys.
The existing dictionary memory layout doesn't support direct indexing (without stepping), so this functionality is not being added as a requirement.
Oh, I'm sorry, I misunderstood. -- Steven