PEP0238 lament

Tue Jul 24 17:25:34 EDT 2001

"Terry Reedy" <tjreedy at home.com> writes:

> 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.

Yes, the arguments pro have been as heated as those against. :-)

I know the PEP author personally, and I assure you he is not of ill
will -- just susceptible to unbridled youthful enthusiasm once he's
identified a good cause. :-)  I will rectify the situation by taking
co-authorship of the PEP, so he won't get the blame.

> 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.

Well, IMO, the current division semantics *are* wrong.  They are very
subtly wrong, just as C's int division semantics are subtly wrong
(they give a less useful result for negative numbers).  The wrongness
doesn't come out immediately, and you can argue about it (so in a
sense it is a religious point) but I am not a cultural relativist, and
I find the proposed new semantics *better* than the old ones --
otherwise I would never have supported the PEP.

I agree that pointing to other languages is unhelpful, unless we
understand what the rationale for the decision in a given other
language is.  As I always say, votes don't count -- arguments do.

I'll address the severe backwards compatibility issues in a separate
post.

> * "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.

Yeah, but not worth arguing about.

> * "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."

This is indeed a poor argument, and not supported by e.g. my survey of
the Python standard library.

> (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?

Good point.

> [snip]

> > > 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 ..."

Sorry.  I didn't realize that your point was that the motivation was
wrong.  I see this now, and I'll rectify it in the PEP.

> 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'.
> '''

Indeed.  I should add that I never meant that the problem was only
important for novices or in an educational setting (I only meant this
as an example of the kind of problems division crates).  Some folks
(like Arthur Siegel) have used a contrary novice's or educator's
experience as a counter-argument to this.  But they fall in the same
trap as most of the other proponents of the status quo: because they
don't use floats much, they don't care that floating point arithmetic
is broken.

> 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.

Hm, IMO the problem is different.  Python's numerical model *almost*
embeds the integers in the floats.  (They should've been called reals,
but that mistake is too insignificant to want to fix. :-) In *most*
situations, where a float is expected, an int works just as well, and
has the same effect as a float with the same mathematical value.
Division is the exception and that's where the problem lies.

But the converse is *not* true in today's Python: code expecting
integers does *not* necessarily work when a float is passed, even if
that float has an integral value.  This is part of the fabric of
Python's semantics.

> 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.

I think that's a good idea, and I'll try.

> > > (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 ;-)

Touche.  I couldn't find that passage in the PEP, and had even gone to
the trouble of searching for "year"... :-(

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