PEP 238 (revised)
tanzer at swing.co.at
Fri Jul 27 11:38:57 CEST 2001
Guido van Rossum <guido at python.org> wrote:
> - Use a directive to use specific division semantics in a module,
> rather than a future statement. This retains classic division
> as a permanent wart in the language, requiring future
> generations of Python programmers to be aware of the problem and
> the remedies.
> - Use "from __past__ import division" to use classic division
> semantics in a module. This also retains the classic division
> as a permanent wart, or at least for a long time (eventually the
> past division statement could raise an ImportError).
> - Use a directive (or some other way) to specify the Python
> version for which a specific piece of code was developed. This
> requires future Python interpreters to be able to emulate
> *exactly* every previous version of Python, and moreover to do
> so for multiple versions in the same interpreter. This is way
> too much work. A much simpler solution is to keep multiple
> interpreters installed.
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
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.
David Bolen expressed this better than me in his answer to your
"""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
> - 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
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.
Christian Tanzer tanzer at swing.co.at
Glasauergasse 32 Tel: +43 1 876 62 36
A-1130 Vienna, Austria Fax: +43 1 877 66 92
More information about the Python-list