Nasty typo in PEP 238 (revised)

[Tim Peters]

[Robin Becker]
>>> when/if the grand unification happens what will math.cos do with 1+3j?
>>> What will floor do with 1.3+0j etc etc etc. Presumably a Timbot thread
>>> is even now busily extending all math functions to the complex domain.

[Tim]
>> My belief is that the vast majority of Python users are best
>> served by the current behavior of never getting a complex result from
>> non-complex inputs unless they explicitly invoke functions from the
>> cmath module.  But that's a question you didn't ask (although you
>> should have).  A more interesting question is whether math.acos(2)
>> should continue to whine.

[Robin]
> so the statement by the grand designer that int/float(x) won't cut it
> if x is complex is just a little fake.

I don't grasp your meaning, but not for lack of trying.

> If complex x hurts in division are we to accept it won't hurt in sqrt?

Sorry, but ditto.  Give a concrete example?  If someone said complex x hurts
in division, I missed it.

> The idea that we might import cmath to get complex '/' to work is
> interesting given the arguments presented about closure for arbitrary
> numerics as inputs to functions.

I haven't seen that idea before, and if you're now *suggesting* it I don't
see any point to it.  Your examples had users explicitly passing complex
inputs to functions.  I was talking about getting complex results out of
functions when complex numbers are *not* passed to them (such as acos(2)).
Division can never return a complex result unless given a complex input.  I
see nothing surprising to anyone about complex-in, complex-out.  It's only
non-complex-in, complex-out that Python currently shields users from (in the
absence of explicitly using cmath functions).  As I said, I think that's a
benefit for the majority of users; I don't know whether Guido agrees.

> Others have been presenting similar schemes to preserve/change the
> natural order of literals etc, but these schemes seem doomed. If OO
> completeness is desirable why shouldn't math.acos is cmath.acos be
> true?

Don't know what "OO completeness" means.  As a pragmatic matter, I would
much rather that the typical business programmer get an exception at the end
of their floating-point algorithm for (say) computing standard deviation,
when due to fp inexperience they use a numerically naive textbook method
that ends up passing a negative number to sqrt due to massive cancellation.
Let that silently return a complex result instead, and God only knows how
much more computation they'll do with it before getting a meaningless result
in the end.  For most users most of the time, a complex result is more
likely a symptom of an error in their code (or uncaught bogosity in their
data) than a useful result.

If you're a Comp Sci Purity Guy, you may want to torture them with 4.02j
instead.

> I accept along with others that there are other numeric models. I don't
> accept the grand unification at face value as some kind of panacea.

Do you believe anyone does?  Not even Moshe has claimed that it would be.

> Before all this brouhaha we didn't really understand any of the real
> problems and I don't believe we can solve them to everyone's
> satisfaction.

This stuff isn't new to me, and I know that we can't.  That doesn't imply
trying to do better would be a net loss.

knowing-you'll-die-in-the-end-isn't-an-argument-against-living-
    either<wink>-ly y'rs  - tim