PEP0238 lament

[Terry Reedy]

http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/python/python/nondist/p
eps/
"Guido van Rossum" <guido at python.org> wrote in message
news:cp3d7ngazy.fsf at cj20424-a.reston1.va.home.com...
> "Terry Reedy" <tjreedy at home.com> writes:
>
> > >and nobody has ever proposed taking away the ability to get an
> > >integer result; the issue is how  to spell that.
> >
> > And that issue was *not* spelled out in the PEP.
>
> Funny, I just checked rev. 1.1 of PEP 238, and it contains the same
> language about adding // as before.  Maybe you never saw the PEP,
but
> assumed the worse based on the discussion?

I just discovered how to access older versions of PEPs and checked
1.3, which I at least partly read and you are right.  My view and
memory of the PEP was distorted by anti-int-div float-div-religion
being pushed as fact by the PEP author and some other proponents, who
continue to this day.  Some current examples nearly identical to
several previous attempts:

* "Many other languages do division correctly - Scheme, Perl and Tcl,
for instance."  My claim: this is a religious statement.  Obvious
implication of such statements: Python currently does division
wrongly.  Subtler implication in at least some statements of this
sort: it is not intelligent to advocate that Python continue doing
division wrongly.

* "Integer division is a lousy tool in this particular example.."
[converting bytes to Kbytes].  Combined with the previous line, this
response denies the possibility of using (bytes + k/2)/k to round (or
that the original poster would have known how to do so) and claims
that int(float(bytes)/float(k)+.5) is factually better.  I disagree.

* "Nobody said [int division] wasn't of any use, people just claim it
is *less* useful, and so should not be the most easily accessible."
(from Moshe himself, last night).  Since in any situation the most
useful form of division is the one that most easily gives the correct
answer, the premise is incorrect.  So why do proponents even now keep
repeating an incorrect and unnecessary claim to justify the change?
Since the difference between '/' and '//' is too trivial to hardly
discuss, I tend to interprete the 'conclusion' to be an attempt, even
now, to justify something that really would be less accessible and
more obnoxious than '//', like div(i,j) or divmod(i,j)[0].  When
proponents of the change keep trying to justify making int div less
accessible, is it any wonder that people think that that is what they
really intend?

[snip]

> > If 238 had been written originally something like the following
(which
> > it now is), I would have argued *much* less.
>
> Shall I rub it in? :-) ...:-)

Since I just recently accepted the long-term desirability of the
change, you're treading on thin ice.   But since you added two smileys
to make sure I saw at least one, I'll take this as good-natured
ribbing.

> > Situation: Python '/' currently overloads and confounds two
arithmetic
> > operations: whole-number result division and fractional result
> > division.  This confuses some people.
> > Proposal: Make '/' consistently mean fractional division and
introduce
> > a new operator '//' for truncated-result division.
> > Acknowledgement: This semantic replacement is a bit different from
> > most any previous change to Python.  Extra care will be needed to
make
> > the transition as smooth as possible.

> This is exactly what the PEP said all the time.

NO, NO, NO!  Contrary to what I said above, it still does not.  Moshe
writes,
"Rationale
    The behavior of integer division is a major stumbling block ..."

This prejudiced view, which too many people have unnecessarily bundled
with the proposed change itself, is quite different from the
division-neutral rationale you quoted above, which locates the
'problem' in the conflict *between* the two meanings.  To repeat:
'''
Situation: Python '/' currently overloads and confounds two arithmetic
operations: whole-number result division and fractional result
division.  This confuses some people.
'''
which I would today follow with:
'''
Contention: Even though there will be many transition problems, it
will be in the long term interest of some current and many future
Python programmers to better separate the two meanings of 'division'.
'''

Proponents have pointed out that if someone writes a function like
def speed(distance, time): return distance/time
without checking inputs for conformance with preconditions and if
function users violate the preconditions (by feeding in two ints in
this case), the function will generally return a subtlely wrong
answer.  Okay, but the same is just as true of
def minmaxpart(n,k): return (n+k-1)/k
The problem is the close overlap of the two meanings, not either in
itself.

I strongly recommend that the PEP Rationale (and Abstract) be
rewritten in a neutral manner starting with something like "The
conflict and confusion between the two closely related meanings of
number division is a stumbling block in the writing of correct Python
programs."  In suggesting that a straightforward, if troublesome,
separation of meanings be divorced from attempts to assign blame to
one of the two meanings, I am attempting to help make the proposal
more palatable to those, like me, who do not and will not accept the
religious-philosophical views behind that assignment of blame.

 > > (Just noticed:  http://python.sourceforge.net/peps/pep-0238.html
> > now proposes a *2 year* int/int warning period starting with 2.3.
It
> > still needs a stipulation that someone write an intdiv checker to
help
> > automate replacements.)
>
> Hm???  I don't see that on the URL you give.  Maybe you live in an
> alternate universe where PEP 238 has a different contents than in
mine?

Your sarcasism is improving, but look again:
'''
PEP: 238
Title: Non-integer Division
Version: $Revision: 1.6 $
...
Changing the Semantics of the / Operator
...
The warning will be off by default in the 2.2 release, and on by
    default for in the next Python release, and will stay in effect
    for 24 months.
'''
Shall *I* rub it in? ;-)  In *my* universe, 24 months is (24/12 =) 2
years ;-)

> --Guido van Rossum (home page: http://www.python.org/~guido/)

Terry J. Reedy