Message236880
| Author |
ncoghlan |
| Recipients |
Arfrever, alex, barry, docs@python, eric.snow, ethan.furman, mark.dickinson, mjacob, ncoghlan, python-dev, serhiy.storchaka, vstinner |
| Date |
2015年02月28日.12:00:50 |
| SpamBayes Score |
-1.0 |
| Marked as misclassified |
Yes |
| Message-id |
<1425124851.13.0.0055077947299.issue17576@psf.upfronthosting.co.za> |
| In-reply-to |
| Content |
OK, something appears to have gotten confused along the way here. Barry's original problem report was that operator.index() was returning a different answer than operator.__index__() for int subclasses. Absolutely nothing to do with the int builtin at all. While the fact int() *may* return int subclasses isn't especially good, it's also a longstanding behaviour.
The problem Barry reports, where a subclassing based proxy type isn't reverting to a normal integer when accessed via operator.index() despite defining __index__() to do exactly that should be possible to fix just by applying the stricter check specifically in PyNumber_Index.
Expanding the scope to cover __int__() and __trunc__() as well would be much, much hairier, as those are much older interfaces, and used in a wider variety of situations. We specifically invented __index__() to stay away from that mess while making it possible to explicitly indicate that a type supports a lossless conversion to int rather than a potentially lossy one. |
|
History
|
|---|
| Date |
User |
Action |
Args |
| 2015年02月28日 12:00:51 | ncoghlan | set | recipients:
+ ncoghlan, barry, mark.dickinson, vstinner, Arfrever, alex, docs@python, ethan.furman, python-dev, eric.snow, serhiy.storchaka, mjacob |
| 2015年02月28日 12:00:51 | ncoghlan | set | messageid: <1425124851.13.0.0055077947299.issue17576@psf.upfronthosting.co.za> |
| 2015年02月28日 12:00:51 | ncoghlan | link | issue17576 messages |
| 2015年02月28日 12:00:50 | ncoghlan | create |
|