PEP 238 (revised)

[Guido van Rossum]

> I was one of those asking for a way to get old-style semantics. 
> 
> Keeping old interpreters around doesn't work for my biggest worry:
> use of old scripts with new versions of TTTech's applications. In this
> context, TTTech ships an application containing a new interpreter to a
> customer who might still have old scripts around. These scripts might
> come from a third party and be totally opaque to the customer itself
> (e.g., a script to import from a tool of company XYZ into TTTech's
> TTPplan). 

Well, I hope that making the change Python 3.0 does the right thing
for you.  It shouldn't be hard to alert your customers that Python 2
is required for your company's applications.  Like Perl 4 and Perl 5,
Python 2 and Python 3 will probably live alongside for many years.

> I agree that exact emulation of old versions doesn't make sense. What
> I would propose is to enable Python somehow to identify old code
> (e.g., by absence of a version specifier) and let it raise an
> exception when `/` is applied to two integer arguments by old code.
> This would avoid both permanent warts and silent breakage of old code.

Requiring a version specifier in all new code is very annoying.  The
future statement is annyoing too, but at least it's a transitional
measure.

> David Bolen expressed this better than me in his answer to your
> updated PEP::
> 
>     """While some number of version implementations may need to be
>     supported for some changes, this suggestion doesn't require them
>     all in perpetuity, so that's slightly misleading. One could easily
>     consider some range of versions being supported (and retired over
>     time), and an advantage of this approach would be accurate (and
>     reportable) breakage if using code expecting version behavior no
>     longer supported."""

I agree that if we really need to have a way to explicitly request
past behavior, "from __past__ import ..." is a decent syntax.  I just
noticed that PEP 236 (the __future__ PEP) mentions this as an
possibility (although the author claims it is unlikely).

> >     - It has been proposed to call // the quotient operator.  I like
> >       this.  I might rewrite the PEP to use this if enough people like
> >       it.  (But isn't the assumption that this truncates towards
> >       zero?)
> 
> IMO quotient is a much better name than floor division. I'll let the
> mathematicians speak on whether quotient and truncation to minus
> infinity can go together.

I just looked it up at dictionary.com, and the meaning of quotient is
just the result of a division.  One source even mentions that the
quotient is rational if the operands are.

So I am less and less in favor of this.

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