PEP0238 lament

[David Bolen]

Guido van Rossum <guido at python.org> writes:

> > It seems to me that the only real argument against that is aesthetics,
> > or am I missing something?  Of course I'll play a little devil's
> > advocate and say that I probably agree with the aesthetic argument, but
> > only to the point where it breaks down against my concern for the
> > compatibility argument.
> 
> I don't see it as just aesthetics.  It's like the alleged bug that
> caused a figter jet to flip over when crossing the equator, a subtle
> bug waiting to happen.

By aesthetics I just meant // being less logical as a CP4E division
operator than /.  You'd still be able to get the
as-accurate-as-possible result, but not with the most obvious operator
syntax.

But even if it was just aesthestics, I don't really like that syntax
either, so I definitely won't press this point :-)

BTW, when I read the PEP my take-away is that the problem behavior is
the int/int yielding int case.  Thus, to me having any single operator
that avoids the int/int->int case would be a potential resolution even
if the existing behavior is untouched.  The PEP seemed less clear that
I guess you also consider a problem that a single operator (/ today)
can yield both int or float as a result depending on operands.  So
perhaps that could be clarified in the PEP?

> I just decided that the new behavior won't become the default before
> Python 3.0.

Personally, the version numbers don't mean as much to me (I don't have
any higher management to "sell" this to), but I do think this may make
others lives a bit easier.

Ideally, this would also permit a few other such issues (if they
exist) to slip in over time during the next few 2.x releases and yet
the real breakage all be clustered in the future 3.0 release.

> > Unlike many (all?) of the prior backwards-incompatible features, which
> > first warn about breaking behavior and then fully break behavior, but
> > continue to do so visibly (e.g., "yield" remains a keyword), this one
> > ends up in a state where the break goes from being warned about to
> > being silent and no longer visible.  That might be part of my gut
> > concern about compatibility, as it makes me feel that there is a
> > window of opportunity to catch the problem, but if you miss it,
> > discovering dependencies on old behavior becomes very problematic.
> 
> Actually, nested scopes shares this property.  It's just that code
> affected adversely by nested scopes is pretty rare.

Drat - I hate it when that happens (losing weight behind an argument
because you've already missed a pre-existing similar case).

> > Doing a static analysis of
> > modules to find uses of division can help inspect older modules but
> > having runtime warnings may prove helpful when trying to make use of
> > an older module in a few years with a current Python.  This sort of
> > thing might even be helpful as a general recommendation for other
> > backwards-incompatible changes that by their nature become silent once
> > fully enabled.
> 
> An easy solution of course is to keep an older version of Python
> around and see if the code triggers any warnings with that version.

Good point.  The difficult part of this might be if testing the module
is part of a larger system that uses newer modules requiring a later
interpreter, but clearly at worst a test harness could be written to
cover that.

--
-- David
-- 
/-----------------------------------------------------------------------\
 \               David Bolen            \   E-mail: db3l at fitlinxx.com  /
  |             FitLinxx, Inc.            \  Phone: (203) 708-5192    |
 /  860 Canal Street, Stamford, CT  06902   \  Fax: (203) 316-5150     \
\-----------------------------------------------------------------------/