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

[Nick Coghlan]

The big problem with generics in the past has been clearly articulating use
cases. A genericmath and updated pprint could help a lot on that front.

--
Nick Coghlan (via Gmail on Android, so likely to be more terse than usual)
On Nov 10, 2011 6:52 AM, "Paul Moore" <p.f.moore at gmail.com> wrote:

> 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.
> _______________________________________________
> Python-ideas mailing list
> Python-ideas at python.org
> http://mail.python.org/mailman/listinfo/python-ideas
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-ideas/attachments/20111110/a847fa89/attachment.html>