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

[Paul Moore]

On 9 November 2011 20:15, Masklinn <masklinn at masklinn.net> wrote:
> This would mean custom numerical types wouldn't be drop-in compatible with existing numerical *code*,
> which I am under the impression is what Case Van Horsen wants (and is a desirable outcome).
>
> Furthermore, your second paragraph is not correct: Case does not propose "changing the behavior of
> built-in modules depending on the presence of another module", Case proposes adding *method hooks*
> to existing math and cmath functions. These would be protocols allowing custom numerical types to
> implement `math`/`cmath`'s operation in a sensible manner, as is already possible for four methods he
> mentions, as well as a number of other Python operations[0], including prominent numerical ones[1].

I like the idea of being able to extend the math functions to allow
user-defined numeric types to behave like built in ones. (In fact, if
this were possible, complex could use it and a large proportion of the
cmath module would be unneeded). However, I have to say that for me
this is a purely theoretical issue - I've never had the need for the
functionality myself in real code, and I doubt I ever will. Given the
proliferation of special methods that would be needed, plus the
runtime overhead of extra checking, I think the cost is likely too
high.

It's also worth noting the preamble text in the math module
documentation - the functions there deliberately only handle floats,
and are thin wrappers over the C standard library. To get any sort of
generic behaviour, users need to use cmath, by design. So as stated
the proposal is unlikely to get much support.

Some alternative suggestions:

1. As already noted, you could include a gmpmath module with the
relevant functions, and users could monkeypatch the math module if
they wanted to do so.

2. To make such monkeypatching easier, publish a module that exposes a
context manager to do the job:
       with monkeypatch(math, 'sin', gmpmath.sin):
           your code here...

3. Write a genericmath module that provides the "generic" versions
you're proposing, and see how much use it gets - if it's sufficiently
popular, you have a better case then for folding the functionality
into at least cmath.

4. As Georg mentioned, numpy's ufuncs have a feature like this, so
support that and people can use your types with numpy. That may be
enough (depending on your expected user base).

Overall, I think the idea of being able to use user-defined types
interchangeably with built-in ones is a good one, but it's not
something Python goes out of its way to support. If the idea of
generic functions had taken off, then this is an area where they would
have fit nicely - but once again, there wasn't much enthusiasm from
the core developers for addressing the types of problem they were
aimed at.

Paul.