-
-
Notifications
You must be signed in to change notification settings - Fork 10.9k
Inconsistent indexing result depending on argument type #6564
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
Comments
Well, that looks weird indeed. Normally I'd ignore this and wait for @seberg to respond, but I think he's on vacation :-) I think what's going on is... well, first, background: Python has a weird calling convention for indexing, where if you write This looks like a bug to me, but it might be one of those bugs that we can't fix without breaking a bunch of code, or where there's some complicated deprecation required or something... probably we should just wait until @seberg gets back because he'll probably know off the top of his head which type of weird case this one is :-) |
exactly, i have an opwn PR to deprecate it, might need some work though. the docs do have a warning somewhere, but the excat rules are a bit funny and nowherr explained greetings from esfahan, iran :). |
There is a warning here http://docs.scipy.org/doc/numpy/reference/arrays.indexing.html#advanced-indexing which basically hints at the problem. IIRC the exact rule is: A sequence is treated like a tuple, if:
The pull request I mentioned is gh-4434, is it time to try this? Maybe another note to the list would be good as well before we do that. @llvilanova if you feel strongly about it, please go ahead :). |
I've just noted it in the list (https://mail.scipy.org/pipermail/numpy-discussion/2015-November/074266.html). Thanks. |
This has a futurewarning now and will eventually change, so closing. |
The following results seem inconsistent to me (numpy 1.9.2):
I've briefly looked at the indexing manual (http://docs.scipy.org/doc/numpy/reference/arrays.indexing.html) and nothing seems to account for this.
Thanks,
Lluis
The text was updated successfully, but these errors were encountered: