On Sun, Sep 18, 2016 at 3:57 AM, David Mertz
For example, '%' is fairly widely (ab)used for meanings other than modulo. E.g. string formatting. Probably not that many classes that respond to '%' to do something non-modulo simultaneously implement `.__divmod__()` ... but maybe some use case is not obvious to me. If those exist, your change would break that (well, depending whether methods of ancestors are used or not).
So there'll be classes that define __mod__ but not __divmod__ - that's fine. Are there any that go the other way around? It might technically be a breaking change, but it's unlikely to cause very much breakage. So it'd be inappropriate for 3.6.1, but okay for 3.7. +1 on the fallback exactly as Ethan described. The One Obvious Way to implement arithmetic division would be to define __divmod__. Defining __truediv__ or __mod__ would be for times when you can implement it more efficiently by not calculating the other half, and of course the times when they're not implementing division (cf pathlib.Path and str, for / and % respectively). ChrisA