Against PEP 240

[Alex Martelli]

"Robin Becker" <robin at jessikat.fsnet.co.uk> wrote in message
news:YXxXCABmYDF7EwPr at jessikat.fsnet.co.uk...
    ...
> >precision -- it seems quite traditional for floating-point fans to
decorate
> >their literals with tasteful 'd', 'e', and/or 'f', not to speak 'l'
> >sometime.
>
> so then it ought to be easy for either side and then the default ought
> to rest with the existing python tradition.

A "traditional floating-point fan" must be somebody with experience
enough to make the concept of syntax decoration easy.  The "other
side" just wants 7.35 to MEAN 7.35, no more, nor less, and would
most likely be hard put to understand the differences between that
being a floating-point decimal number, or a rational -- in EITHER
case, 7.35 would MEAN 7.35, the key issue.

I wish all Pythonistas had a modicum of experience teaching Python
to newbies that are skeptical enough of techies to NOT be sold a bill
of goods.  Just TRY to explain:

D:\py21>python
Python 2.1 (#15, Apr 16 2001, 18:25:49) [MSC 32 bit (Intel)] on win32
Type "copyright", "credits" or "license" for more information.
Alternative ReadLine 1.1 -- Copyright 2001, Chris Gonnerman
>>> 7.35
7.3499999999999996
>>>

to three such people to which you have been promoting Python as a
language easy to use AND UNDERSTAND.  Now they find out that, to
deal with such an elementary concept as "7 dollars and 35 cents",
they first have to get a major in advanced computer science, else
BY DEFAULT 7.35 does not MEAN 7.35, it means 7.34999 etc.

If you try to explain it away by saying "it's a tradition", they'll rightly
look at this as akin to a "traditional" hazing of fraternity pledges -- an
ordeal they'd have to go through if they wanted to become insiders.
Remember to ALWAYS write, e.g, 7.35r, NEVER 7.35 as you should
so OBVIOUSLY be able to, or else you get paddled.

Most things in Python have pretty solid logic behind them -- enough
to convince an intelligent newbie that, yes, there ARE good reasons
for things to work that way by default, if one explains carefully and
patiently.  Having to fall back to "well if it was good enough for my
grandfather it must be good enough for me" JUST WON'T CUT IT, and
most particularly if granddad (as is not unlikely given the ratio of
Cobol+xBase+&c vs others in number of programmers) used a
language where 7.35 *MEANS* 7.35.


> >> If we're forced to use 'f' or 'F' I don't mind. We can do double
> >> precision in the same way ie use 'D'.
>
> ... the word here is 'forced' I don't want this and I don't  want an
> easy way into possibly very large computations ie let's use rationals
> and Newton's method to solve for a root of x^2 = 2
>
> A naive user might expect an exact result.

When people get so advanced into numerics as to deal with
Newton's method, they're easily advanced enough to append
an 'f' to those rare literals they truly need to be in binary
machine floating-point.


> >> Are complex numbers, floats and rationals and ints to be freely
mixable?
> >
> >I don't see why numeric types should be any less mixable if/when
> >PEP 240 takes over than they are now.
>
> if they are do we get to see/hook the various conversion methods.

A PyObject comes with a slot pointing to numeric methods, including
conversions.  This should remain, it seems to me, so extensions just
keep working.  Not sure what you mean by 'hook' here.


Alex