Message178377
| Author |
mark.dickinson |
| Recipients |
chris.jerdonek, ezio.melotti, georg.brandl, gregory.p.smith, mark.dickinson, python-dev, serhiy.storchaka |
| Date |
2012年12月28日.09:33:09 |
| SpamBayes Score |
-1.0 |
| Marked as misclassified |
Yes |
| Message-id |
<1356687190.2.0.981483017803.issue16772@psf.upfronthosting.co.za> |
| In-reply-to |
| Content |
I'd suggest leaving 3.2 and 3.3 as they are: the bug is fairly benign, but fixing it could break existing code unnecessarily. That's something that we should try hard not to do in a bugfix release.
As to PyNumber_AsSsize_t() used instead PyLong_AsLongAndOverflow(), I *do* think that in general interfaces for built-in functions and methods that accept an integer should be prepared to accept anything that has an __index__. If we can find a way to do that with sane exception types / messages, so much the better. (One common application of __index__-able types occurs when using NumPy, where it's easy to end up with instances of numpy.int32 or numpy.int64 instead of regular Python ints.) I agree with Serhiy that ValueError is the appropriate exception for out-of-range values.
[A side-issue here is that the various PyLong_As* utility functions are a mess: some use __int__, some use __index__, etc. I have some thoughts about how to fix this, but that's another issue.] |
|