PEP 238 (revised)

Paul Boddie paul at boddie.net
Mon Jul 30 05:32:47 EDT 2001


Joshua Macy <l0819m0v0smfm001 at sneakemail.com> wrote in message news:<3B61E456.78DFE802 at sneakemail.com>...
> 
>   It seems to me that if upon reading the PEP someone thinks "How on
> Earth am I going to know what needs changing?", he is almost guaranteed
> to have bugs in his code that relate to the very issue that the PEP
> addresses.  How could he not, since he's obviously never thought about
> it before?

He hasn't needed to think about changes to his division-utilising code
before because no-one proposed a fundamental change to the division
operator before. It's obvious that "places where division is used" may
be affected, but it's possible that not all of them will be, just as
it's possible that areas of the code "around" the division may need
changing too.

>  Someone who thinks this way should be thanking his lucky stars that if the
> PEP is implemented the language is going to grow the machinery in the near
> term to help him identify the bugs (warnings and possibly tools), write code
> that's not subject to the bugs (using / and // appropriately) and the
> incentive (Python 3.0) to attack the problem in the next few years.

It's certainly an interesting perspective you have. One writes code
according to the published, well-defined and longstanding semantics of
a particular operator in a programming language (namely those which
dictate that the / operator yields a particular style of integer
result when presented with two integer operands but a different style
of floating point result when presented with at least one floating
point operand), but then these semantics are then changed so that a
floating point value (of the latter style) results in such cases.

In your opinion, it is not sufficient to read the documentation
carefully and comply with it, but also to second-guess the language
designer's future intentions. I can't wait for people to start posting
to comp.lang.python about how the examples in the Python books they
have just bought all give the wrong answers. Perhaps Python book
authors should start producing the errata for their books now, given
that those books must all contain plenty of "bugs" too.

Yes, I would hope that the language does "grow the machinery" to help
people deal with this, and expect that people don't have to deal with
it until such machinery is in place.

Paul



More information about the Python-list mailing list