Against PEP 240

[Alex Martelli]

"Robin Becker" <robin at jessikat.fsnet.co.uk> wrote in message
news:WrYUdKAGE$E7EwEI at jessikat.fsnet.co.uk...
    ...
> >> My main objection is that this is likely to bust just about any
> >> extension that uses floating point.
>
> If I have made a really fast vector multiplier for floats I might use
> myfastmult((1.0,2.0),(3.0,4.0)); if I was being really speed conscious I
> would always assume that this function was being used with floats. It
> would go wrong if I used the same call. I now have to either force the
> conversion internally (which slows things down) or locate and change
> every call of the function.

Exactly!  The extension isn't disturbed one bit: when it calls
its PyFloat_AsDouble's, exactly like today, there may be
some conversion (nb->nb_float(op) is called, where nb is the
PyNumberMethods* obtained by op->ob_type->tp_as_number)
if needed (if it uses PyFloat_AS_DOUBLE instead, it's arguably
broken already...:-).  The *Python sources* using the extension
will be a bit slowed down until and unless you find the time to
run a script on them all to change your \d+\.\d+'s by appending
an F to them.  Is that your definition of "bust"...?


> >Can't you do interval arithmetic today, btw?  Quite apart from
> >the issue of what a literal 7.35 means?
> ...
> I can do interval type arithmetic with a class definition no problem. If
> we're allowing new literals and the like I might want to have an
> interval literal like (1,2)I :)

And would that improve your quality of life noticeably when
compared to the I(1,2) notation for the same thing that you can
already use today...?


Alex