[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/