[Python-ideas] Add additional special method lookups to math module

Steven D'Aprano steve at pearwood.info
Thu Nov 10 00:02:29 CET 2011


Case Van Horsen wrote:
> Currently the functions round(), math.ceil(), math.floor(), and
> math.trunc() all check for the existence of a special method
> (__round__, __ceil__, __floor__, and __trunc__). Would it be possible
> to enhance the math and cmath modules to check for the existence of a
> special method for (almost) functions? For example, math.sin(obj)
> would first check for obj.__sin__.

I would not object to this.

The only function I can honestly say I have had a concrete use-case for 
is math.sqrt. This comes up from time to time, e.g.:

http://bytes.com/topic/python/answers/463861-how-overload-sqrt-module
http://permalink.gmane.org/gmane.comp.python.general/694849

However, how far should we go? Does every function in the math module 
require a dunder method, e.g. __degrees__ ? What happens if we add more 
functions, say math.bessel? Do we really expect that all numeric types 
must support a __bessel__ method? I suspect that this proposal is 
actually bigger than it seems at first glance.

We can:

* Do nothing (the status quo). If you write a numeric type, you can 
support a small number of mathematical operations, such as + and 
math.floor, but not others, such as math.sqrt or math.sin.

* Officially recommend that people monkey-patch the math module if they 
want to write a drop-in replacement for numeric types. I consider this 
unspeakable, but mention it for completeness since others have raised 
the possibility.

* Add support for dunder methods in an ad hoc manner, when and as 
requested, without making any promises about any other functions.

* Add support for dunder methods in a systematic way. This would require 
distinguishing between fundamental operations that should support dunder 
methods, and those that shouldn't (if any). This will probably need a PEP.

* Instead of having to decide what operations should be supported ahead 
of time, perhaps there is a way for types to register themselves with 
the math module, e.g. say "I support sin, but not sinh". Somewhat akin 
to the way ABCs work, at least conceptually. One advantage of that may 
be that numeric classes won't have to use dunder methods for supporting 
the math module, e.g. MyNumber might register sin rather than __sin__.


-- 
Steven




More information about the Python-ideas mailing list