Nasty typo in PEP 238 (revised)

[Robin Becker]

In article <mailman.996274552.18788.python-list at python.org>, Tim Peters
<tim.one at home.com> writes
>[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.
>
>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.

so the statement by the grand designer that int/float(x) won't cut it if
x is complex is just a little fake.  If complex x hurts in division are
we to accept it won't hurt in sqrt?

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. 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?

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.
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.
-- 
Robin Becker