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
_______________________________________________
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at
https://mail.python.org/archives/list/python-ideas@python.org/message/FXRP465KOBIB7DABEPHVNX4S2EOXVXWU/
Code of Conduct: http://python.org/psf/codeofconduct/
