-
-
Notifications
You must be signed in to change notification settings - Fork 29.2k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Generic types accept indexing/subscripting, causing confusion #86176
Comments
While writing the docs for PEP-585's GenericAlias, I noticed that the following anti-pattern described in PEP-585 no longer throws an error when it should:
Whereas in versions of Python before 3.9, a "TypeError: 'type' object is not subscriptable" would have been thrown. Quoting PEP-585 again: "Say, if a user is mistakenly passing a list type instead of a list object to a function, and that function is indexing the received object, the code would no longer raise an error." Although the context of that statement isn't the same. I fully agree with its reasoning. This makes Python more confusing for beginners coming from other languages too: // in c, makes a 10 element array
int l[10]; # now in python, this is fine This may give beginners the false impression that an empty 10 element list has been created. I have created a PR and a test for this. The changed code blocks ints, floats, bools and complex from indexing for type objects. str is allowed since list['mytype'] seems analogous to typing.List[ForwardRef('mytype')]. Also, imo beginners are unlikely to accidentally write that code while intending to index a list. Feedback is greatly appreciated, as I've not touched the C codebase in cpython before. Thanks! |
I'd like to clarify the following too, currently: (1)
>>> list[1]
list[1]
(2)
>>> list[1, 2, 3]
list[1, 2, 3] The PR only solves (1) and not (2), is (2) intended behavior? |
Have you observed actual users getting confused by this? (E.g. StackOverflow or mailing list posts.) I would assume that if you try to *do* anything with the resulting object it's going to cause a traceback, and from there it's pretty straightforward to debug the situation. (Maybe not for absolute beginners, but they have a lot of ways to confuse themselves. :-) There are people working on proposals for "integer variadics" that would actually give meaning to things like list[10] (or at least to A[10] and A[N, M] where A is a tensor type) so I am reluctant to forbid this now -- we might have to allow it in the next release. |
Partly due to Python 3.9.0's nascency, I've not been able to find online cases of beginners getting confused by this specific behavior. Wow I didn't know about integer variadics, assuming they make their way into 3.11, I can see why it'd be better to leave that in for now. I'm going to close the PR, and if there are no more discussions in the next 30 days, I'll close this bug report too. Thanks for clarifying. |
Subscription of list and dict (only with '') and ??? is at least puzzling. Removal of a new feature after release is a bad idea. But this new feature, expansion of subscription, needs to documented in The current first line "A subscription selects an item of a sequence (string, tuple or list) or mapping (dictionary) object:" is no longer always true. This suggested replacement is: "Subscription of a sequence (string, tuple or list) or mapping (dictionary) object selects an item from the collection." Then at the end, add something like "Subscription of certain type objects creates a Generic Alias. where 'Generic Alias links to where such are documented. |
That sentence has been a lie for a long time (from the start?). Any type can define __getitem__ and get this behavior, though in this case it is done through __class_getitem__ (PEP NNN). |
I think kj's patch is ready to merge. Guido, do you want to take a look? |
Note: these values reflect the state of the issue at the time it was migrated and might not reflect the current state.
Show more details
GitHub fields:
bugs.python.org fields:
The text was updated successfully, but these errors were encountered: