<p>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. </p>
<p>--<br>
Nick Coghlan (via Gmail on Android, so likely to be more terse than usual)</p>
<div class="gmail_quote">On Nov 10, 2011 6:52 AM, "Paul Moore" <<a href="mailto:p.f.moore@gmail.com">p.f.moore@gmail.com</a>> wrote:<br type="attribution"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
On 9 November 2011 20:15, Masklinn <<a href="mailto:masklinn@masklinn.net">masklinn@masklinn.net</a>> wrote:<br>
> This would mean custom numerical types wouldn't be drop-in compatible with existing numerical *code*,<br>
> which I am under the impression is what Case Van Horsen wants (and is a desirable outcome).<br>
><br>
> Furthermore, your second paragraph is not correct: Case does not propose "changing the behavior of<br>
> built-in modules depending on the presence of another module", Case proposes adding *method hooks*<br>
> to existing math and cmath functions. These would be protocols allowing custom numerical types to<br>
> implement `math`/`cmath`'s operation in a sensible manner, as is already possible for four methods he<br>
> mentions, as well as a number of other Python operations[0], including prominent numerical ones[1].<br>
<br>
I like the idea of being able to extend the math functions to allow<br>
user-defined numeric types to behave like built in ones. (In fact, if<br>
this were possible, complex could use it and a large proportion of the<br>
cmath module would be unneeded). However, I have to say that for me<br>
this is a purely theoretical issue - I've never had the need for the<br>
functionality myself in real code, and I doubt I ever will. Given the<br>
proliferation of special methods that would be needed, plus the<br>
runtime overhead of extra checking, I think the cost is likely too<br>
high.<br>
<br>
It's also worth noting the preamble text in the math module<br>
documentation - the functions there deliberately only handle floats,<br>
and are thin wrappers over the C standard library. To get any sort of<br>
generic behaviour, users need to use cmath, by design. So as stated<br>
the proposal is unlikely to get much support.<br>
<br>
Some alternative suggestions:<br>
<br>
1. As already noted, you could include a gmpmath module with the<br>
relevant functions, and users could monkeypatch the math module if<br>
they wanted to do so.<br>
<br>
2. To make such monkeypatching easier, publish a module that exposes a<br>
context manager to do the job:<br>
       with monkeypatch(math, 'sin', gmpmath.sin):<br>
           your code here...<br>
<br>
3. Write a genericmath module that provides the "generic" versions<br>
you're proposing, and see how much use it gets - if it's sufficiently<br>
popular, you have a better case then for folding the functionality<br>
into at least cmath.<br>
<br>
4. As Georg mentioned, numpy's ufuncs have a feature like this, so<br>
support that and people can use your types with numpy. That may be<br>
enough (depending on your expected user base).<br>
<br>
Overall, I think the idea of being able to use user-defined types<br>
interchangeably with built-in ones is a good one, but it's not<br>
something Python goes out of its way to support. If the idea of<br>
generic functions had taken off, then this is an area where they would<br>
have fit nicely - but once again, there wasn't much enthusiasm from<br>
the core developers for addressing the types of problem they were<br>
aimed at.<br>
<br>
Paul.<br>
_______________________________________________<br>
Python-ideas mailing list<br>
<a href="mailto:Python-ideas@python.org">Python-ideas@python.org</a><br>
<a href="http://mail.python.org/mailman/listinfo/python-ideas" target="_blank">http://mail.python.org/mailman/listinfo/python-ideas</a><br>
</blockquote></div>