PEP0238 lament

Stephen Horne steve at lurking.demon.co.uk
Mon Jul 23 02:39:15 EDT 2001


On Mon, 23 Jul 2001 10:42:10 +0700, "Andy Salnikov"
<salnikov at inp.nsk.su> wrote:

>
>"Robin Becker" <robin at jessikat.fsnet.co.uk> wrote in message
>news:vyIKbWAP62W7EwC+ at jessikat.fsnet.co.uk...
>>
>> I think that is wrong, but I use python in a professional capacity. I
>> think languages succeed or fail because they work for programmers.
>
>Yeah, completely agree. Personaly, if this change happens, it will be a big
>revolt from Python for me. Not only for aesthetic reasons, simply because I
>cannot rely on the language which dares to change the meaning of existing
>operators. What do you think will be next? Change assignment to work like a
>copy, because there are many people confused with the reference semantic? I

EXACTLY.

I do, in fact, occasionally get confused by the reference behaviour in
Python - expecting copies and getting references and visa versa,
especially when I havn't used it for a while. I'm used to being
explicit about when I'm dealing with references, and occasionally
having something behave as a reference when I didn't tell it to can be
a surprise. But I wouldn't propose changing this in a million years -
too much code would break.

There is only one other way I'd accept this change quietly. Support
some kind of version declaration in source files - a bit like 'from
__future__ import', but not implying the new behaviour will be
standard in the next version up.

How about...

from __standards__ import v22_base, sloppy_thinking_division

It should not prevent the use of new constructs, but new semantics for
old syntax should only occur if requested.

It would still leave a bad taste, but at least it doesn't mean
spending months debugging code that currently works.

>Guys, if you really need something returning floats for division, make it
>new operator, I guess everyone could be made happy with 1/2 == 0 and 1//2 ==
>0.5.

Absolutely. I could *ignore* that ;-)

In fact, document '//' as the alternative for the traditional division
sign '÷'. If it really is for the benefit of newbie non-programmers to
delay the integer division lesson until it can really bite them -
maybe when they first learn binary searches and can't figure out why
theirs never terminates, for instance - then they are probably just as
shocked not to have a ÷ symbol anyway.




More information about the Python-list mailing list