[Patches] import floatdivision # 1/2==0.5

M.-A. Lemburg mal@lemburg.com
Tue, 13 Jun 2000 15:24:09 +0200


David Scherer wrote:
> 
> [Greg]
> >> If a module is designed to use float division, then it includes
> >> the thing at the top. If just a single function wants it, then
> >> the "import" (which it really isn't) occurs in the function body.
> >> Want it for a class? Then do the import in the classdef portion,
> >> before the method definitions.
> 
> Correct.
> 
> [MAL]
> > Still, I'd rather like to see some kind of pragma keyword
> > for these kind of semantic changes...
> 
> Some background might be appropriate here.  I am working with some
> professors who write physics textbooks.  For a few years, they have been
> teaching all of their (non-CS) students to write graphical simulations,
> using an obscure language called cT.  This is a real "CP4E" environment: we
> have two 50-minute class periods to teach graphics programming to
> nonprogrammers.  Beginning in September, we will be switching to Python and
> a 3D graphics library I've written for Python
> (http://sourceforge.net/projects/visualpython)
> 
> We need floating point division.  Because we are trying to make our
> environment available on UNIX, we want it to be part of standard Python in
> some form.
> 
> My first suggestion (made to idle-dev and discussed briefly on python-dev)
> was to make 3/4==0.75 the default, and provide backward compatibility with
> the 'global' keyword.  The ha.. er, implementation :) works exactly the
> same, and is also lexically scoped.
> 
> global olddivision   # does nothing on Python 1.5.2
> print 3/4  # 0
> 
> This is obviously a much bigger change than the "import", since it changes
> the default behavior of the language.  "import floatdivision" is intended as
> a compromise: it permits us to experiment without inconveniencing anyone.
> There are a variety of other possibilities, from file extensions to new
> keywords.

I like your lexically scoped fix (changing / to globally
mean float division would break huge amounts of code and be
very hard to track down)... not sure what Guido thinks about this,
though.

What I don't like is the misuse of 'import' to trigger
the change. IMHO, it would be worthwhile designing a
general solution to this problem, which also allows setting
values.

The background here: we will be moving towards different
source encodings in 1.7 and there'll be a need to define the
encoding somewhere in the code for the compiler to use.
Some kind of 'pragma encoding:latin-1' would be needed --
much like your 'pragma division:coerce-to-float'.

It's a new keyword, but a potentially useful one :-)

> > Seriously, neither import nor pragma will help newbies
> > make use of  '·/·' ::= '·/float(·)'.
> 
> We disagree.  At worst, we can simply tell students up front that they need
> to type "import floatdivision" at the beginning of every program, because
> otherwise 3/2 is one, and that leads to hard-to-find bugs.  I don't think
> it's a difficult habit to learn.

The other around is neither ;-) (Note that in C/C++ 3/2 also gives 1.
Don't know about Java, but it's probably the same there too.)
 
> Programming environments such as IDLE could be configured to insert "import
> floatdivision" at the top of a new file, leaving it up to the experienced
> programmer to remove it.  More specialized environments could even change
> the behavior silently.  The point is that having the flag in the language
> gives 'CP4E' researchers room to experiment, even on platforms like Linux
> where the interpreter is a system resource and can't be replaced.

Agreed.

-- 
Marc-Andre Lemburg
______________________________________________________________________
Business:                                      http://www.lemburg.com/
Python Pages:                           http://www.lemburg.com/python/