On Sun, Sep 18, 2016 at 3:57 AM, David Mertz <me...@gnosis.cx> wrote:
> 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

+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).

Python-ideas mailing list
Code of Conduct: http://python.org/psf/codeofconduct/

Reply via email to