Mark Dickinson <dicki...@gmail.com> added the comment:
Yes, I think there's a lot of history here that obscures the picture.
We have mechanisms in Python to allow 3rd party objects to be interpreted as
floats (via __float__) or as integers (via __index__).
So np.int64 (for example) doesn't subclass int (on Python 3), but is usable as
an integer almost everywhere that that makes sense because it defines __index__
(and __int__, but it's __index__ that really matters here).
If you're writing something bool-like in a 3rd party library, and you want it
to be duck-typeable as a boolean in calls that expect a boolean flag, what
special method should you implement? It seems clear to me that the answer
should be __bool__, but the current error message appears to be telling the
NumPy folks that if they want this to work then np.bool_ should (continue to)
implement __index__. That feels odd to me: it's a completely legitimate and
sensible choice on NumPy's part to decide that np.bool_ objects *aren't*
integers, and shouldn't implement __index__.
The NumPy bug report demonstrates that the concern isn't hypothetical: np.bool_
really *is* a boolean type, and it's easy and natural for a NumPy user to end
up passing an np.bool_ instance instead of a bool instance where a flag is
expected, and then rather surprising when that doesn't work as expected. I've
run into this myself on occasion (turns out that PyQt doesn't like np.bool_
objects either, but that's another story).
The one disadvantage that I can see of allowing arbitrary objects to be used as
flags is the potential for surprising failure modes when a function is
accidentally misused. For example, it could be surprising if something like:
> "aaaXbbbXccc".splitlines("X")
returned ["aaaXbbbXccc"] instead of raising as it currently does. But many
flags are keyword-only, which would make it harder to run into this sort of
thing accidentally.
In short, I think this particular case _is_ a bug that should be fixed.
----------
_______________________________________
Python tracker <rep...@bugs.python.org>
<https://bugs.python.org/issue37980>
_______________________________________
_______________________________________________
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
