Comment on PEP-0238

[Steve Holden]

"Paul Prescod" <paulp at ActiveState.com> wrote in ...
> "Robert J. Harrison" wrote:
> >
> >...
> > The current coercion rules are simple, easy to grasp, and consistent
> > with how most people are taught arithmetic.
>
> That is simply not true. Most people do not expect these four
> expressions to yield different results:
>
> 1.0/3.0
> 1/3
> 1.0/3
> 1/3.0
>
> If you were taught this in school, it must be "new math".
>
Actually, in my case it's "old fart programming". You've got a
floating-point arithmetic unit? You're lucky. I remember, when I were a lad,
we 'ad to take the digits ... [drools into beard & continues to mumble].

But, in fact, I don't think it's that unreasonable to expect binary
operations on integers to be closed over the integers, and devil take the
overflows and fractional remainders. This may, however, sinly be a result of
my having done it that way in countless programming languages over the
years. I have seen the discussions about what "most people" expect, and
remain unconvinced. Since I'm not going to be doing the implementation,
though, I don't grumble *too* much.

I do, however, worry about possible code breakage. I think that changing
integer arithmetic will cause many more users of existing program to be
confused than newbies who have ot understand the present rules. Sometimes
you just have to say "that's the way things are".

> >...
> >   2) Integers should be treated as a distinct type from reals with
> >      automatic coercion only as necessary (with the current rules).
>
> What is "necessary"? Why is automatic coercion *ever* necessary? Only to
> simulate the mathematics we are taught in primary school where the above
> statement are all equivalent.
>
> >      For instance, the new proposal sensibly does not suggest that lists
> >      should support real indices,
>
> That might well be an implication of PEP 228.
>
> http://python.sourceforge.net/peps/pep-0228.html
>
Of course dictionaries already treat equivalent numeric values as equal
keys, hence:

>>> d = {1: "Hello, Paul"}
>>> d[1.0+0j]
'Hello, Paul'

However, anyone relying on exact equality of floating-point values is likey
to be disappointed at some stage unless they know *exactly* what they're
doing. Then, they'll just be occasionally surprised :-)

> >  however simple expressions such
> >      as a[i/3] would have to be coded as a[int(i/3)] or a[i//3]
> >      in order to be sure to avoid a type error.
>
> You mean that you would have to say exactly what you mean according to
> the new syntax. That's hardly a legitimate argument against the syntax.
> "If you add a 'function' keyword, I would have to precede my function
> calls with it." Well, yeah, that's the point of adding new syntax.

If reals are allowed as list/tuple subscripts then

i[1.0]

will be valid, but

i[1.1]

will (I hope) not. Peronally I can't help feeling that

"Subscript not exact integer value"

might also be a little hard for newbies to cope with. Let alone "Subscript
value is not exact" even when the recorded value *is exactly* integral.

Still, I don't have to implement all this stuff, so if the development team
think it's worthwhile then that's fine. Just trying to point out a few
gotchas, which probably won't even be previously unconsidered.

regards
 Steve