PEP0238 lament

[Erik Max Francis]

Guido van Rossum wrote:

> Erik Max Francis <max at alcyone.com> writes:
> 
> > Indeed.  If this is implemented, it will be a black eye for Python. 
> > Any
> > anti-Python advocate will be able to point at this and say, "Look,
> > that's why you shouldn't switch to Python.  The semantics of the
> > builtin
> > operators changes from release to release."  Problem is, they will
> > be
> > absolutely right.
> 
> This seems to be the crux of the anti-PEP-238 sentiments, and I want
> to take it very, very seriously -- without losing the PEP.
> 
> If you agree that, if it weren't for breaking old code, PEP-238 would
> make Python a better language, what can we do about that old code?

I wouldn't say that _that_ issue is the primary one, nor that I would
agree that PEP 238 semantics are preferable.  Since I have your ear for
the moment, let me try and summarize my feelings on the situation.

I would categorize the objections to PEP 238 into three categories:

1.  Making such changes is backward incompatible, something that is
universally agreed to be very dangerous.    If Python had always done
division as in PEP 238, then this would be a non-issue.  But since it
wasn't, changing it will break code.  Even if this change is forced very
gradually, or a very long period of time, there will _always_ be legacy
code around (either passed around from person to person or at a client
site that is inaccessible).  In the latter case, the customer is forced
to 1. hire a consultant to fix it, 2. get patches from the original
author (if he's still around), or 3. trash the system and start over
again.  Similar concerns are how to write portable Python code (portable
across multiple versions that is) if fundamental operators are changing.

2.  Many responders don't agree that the division semantics described in
PEP 238 are favorable in the first place, for a wide variety of reasons.
The responses in this newsgroup don't constitute a poll, of course, but
it appears there is more than just a handful of people who disagree with
the division semantics in PEP 238.  It's unfortunate that such a change
is being considered when it doesn't even seem to be an overwhelming
opinion.  Some also question whether the intention of the change (to
make Python easier for newbies) will even achieved by the change.

3.  Doing PEP 238 means changing the semantics of a fundamental
operator.  This sets a very bad precedent, and makes Python advocacy
harder if such things continue to happen.  If PEP 238 and similar PEPs
get approved and implemented, then someone against using Python can
simply point out that Python is a moving target and coding against it is
a risk, and they'd be right.

Now people have been making these different points with different
strengths.  Some (including admittedly myself) have been a little too
forceful in pointing them out.  Point 3 is a PR issue and point 2 is a
matter of (differing) opinion.

I think what the impartial and objective complaints about PEP 238 can
boil down to here is concerning point 1.  PEP 238 constitutes a
significant (i.e., code-breaking) change in the way a fundamental
operator works.  The question of whether Python should have behaved like
PEP 238 when it was first implemented is a separate question (it is of
course true that if it did, nobody would complaining about it now
because it would simply be the way things were), but the hard fact is
that changing it now is going to break a monumental amount of code, and
some of that code is going to be in place that are not easy to fix. 
Nobody's talking about the technical aspects of fixing it, of course;
we're talking about the logistical aspects of fixing code that is no
longer necessarily easily accessible.

Now that I've hopefully summarized the anti-238 sentiments, let me
continue with your proposal.

> I propose the following measures.  Let's discuss whether these are
> conservative enough, from the perspective of someone who has a large
> body of old working Python code.  (From the perspective of someone who
> wants int division for other reasons, these can never be conservative
> enough. :-)
	...
> Anything else?

Unfortunately, I'm afraid this still doesn't address legacy code that is
longer easily "just fixed."  I can't really think of any reasonable way
to do that, except have vendors tie their scripts to a certain version
and (potentially) force customers to install multiple versions of Python
to get scripts with different version requirements running.

I would argue that Python popularity has reached a threshhold where
fundamental changes to the language are getting to be less and less
feasible, even if very well intentioned.  We'd be seeing the same
objection to a PEP even if the intent and goal were universally hailed
to be laudable.

What concerns me most about PEP 238 -- or rather, your interest in
implementing it -- is that it sets a very disturbing precedent.  One
might ask (without cynicism or rudeness):  Are there other
code-breaking, fundamental changes lurking in the dark that we should
know about?  Is this going to be among the first in a long sequence of
changes that will culminate in Python X being a substantially different
language than Python 1.5.2 or Python 2.1, or is this just an isolated
incident?

The issue is if that a code-breaking PEP is being considered, engineers
need to know about it _now_ so that they can implement their software to
use constructs that will not be affected by Python upgrades in the
distant future when their code is lurking on some client machine, nearly
forgotten but still being regularly used.

-- 
 Erik Max Francis / max at alcyone.com / http://www.alcyone.com/max/
 __ San Jose, CA, US / 37 20 N 121 53 W / ICQ16063900 / &tSftDotIotE
/  \ I want a martini that could be declared a disaster area.
\__/ Capt. Benjamin "Hawkeye" Pierce
    Physics reference / http://www.alcyone.com/max/reference/physics/
 A physics reference.