PEP0238 lament

David Boddie david at boddie.net
Fri Jul 27 15:17:17 EDT 2001


piet at cs.uu.nl wrote in message news:<uae1qeqmt.fsf at cs.uu.nl>...
> >>>>> david at boddie.net (David Boddie) (DB) writes:
> 
> DB> So, if you're already resigned to that then just changing __future__
> DB> to something else like
> 
> DB> from __behaviour__ import float_division
> 
> DB> would be just as easy, and wouldn't break existing code. <wink>
> 
> This just won't work. The most important reason for the change in division
> is that people are caught by the integer division by surprise. So anything
> special that they have to do to get float division will not help. That's
> also the reason that it won't help to introduce // for the new behaviour
> and leave / for the old behaviour.

It was something of a cheeky suggestion on my part given that, until
float division becomes standard, you'll have to use an import
statement anyway.

I wouldn't suggest using // for float division anyway, for reasons
that I've stated before elsewhere.

People are caught out by integer division in two separate instances,
as far as I can tell: when using the interpreter interactively, and
when writing modules. I'm usually caught out in interactive mode,
using Python as a notepad for numerical work. The per module solution
could be used to eliminate this trap by making float division the
default in interactive mode. It wouldn't help the authors of modules,
though.

> I have an idea that might help the transition to become less painful:
> Like someone else noticed about the transition in LaTeX from 2.09 to 2e
> (\documentstyle vs. \documentclass):
> If python files for the 3.0 version and beyond could be recognized then at
> least old files will not be silently executed with the wrong semantics.
> 
> So we could require that in Python 3+ python files have to start with:
> module name
> 
> This doesn't even require module to be a keyword. name should be the same
> name to import the file (i.e. the filename).
> 
> From Python 3.0 onwards files without a module statement should no longer
> be accepted. These must be repaired, i.e. checked for integer divisions and
> a module statement added. So they can no longer silently break.
> 
> In the transition period both forms should be acceptable with the old form
> finally producing warnings.
> 
> The module declaration could also be given parameters to specify a specific
> behaviour, e.g. it could specify that this module wants the old integer
> division:
> 
> module mymod (int_div).

It's an interesting proposal, especially given that lots of scripts
start with extras like

#! /usr/bin/python

or whatever and nobody really objects to this platform specific
intrusion.

Unfortunately, this stands as much chance of being supported as the
per module import proposal since both require the language to carry
"baggage"... :-(

It's strange. I don't mind the introduction of default float division
at some point in the future, despite having to rewrite many of my
modules with no future-proof, succinct integer division operator to
hand. However, diplomatic attempts to avoid breakage of legacy code
appear to have failed. I suspect that the best we can hope for is
non-silent breakage via compile-time exceptions.

Diplomatically-y'rs - David



More information about the Python-list mailing list