This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Author mark.dickinson
Recipients mark.dickinson, serhiy.storchaka
Date 2016-05-11.09:45:22
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <1462959922.42.0.325762734547.issue26983@psf.upfronthosting.co.za>
In-reply-to
Content
> As I understand, the conclusion of the Python-Dev discussion is that __int__, __float__, __complex__, etc should return exact int, float, complex, not subclasses.

Agreed; that matches my understanding. I'm only observing that it would be difficult (and likely undesirable) to actually enforce that `__int__` itself always returns an exact int: I'm not sure where that check would/could take place, and I'd expect that a direct user-level call to `my_object.__int__` probably wouldn't be subject to such a check. What we *can* do is check that the result of the `nb_int` call is always an int in the places we use it.

Or we could even go further, and write custom slot_nb_float and slot_nb_int functions in Objects/typeobject.c that incorporates those checks. What I don't think we can do is check that a *direct* call to `__int__` or `__float__` always returns something of the exact type.
History
Date User Action Args
2016-05-11 09:45:22mark.dickinsonsetrecipients: + mark.dickinson, serhiy.storchaka
2016-05-11 09:45:22mark.dickinsonsetmessageid: <1462959922.42.0.325762734547.issue26983@psf.upfronthosting.co.za>
2016-05-11 09:45:22mark.dickinsonlinkissue26983 messages
2016-05-11 09:45:22mark.dickinsoncreate