Future division patch available (PEP 238)

[Arthur Siegel]

>I'm cc'ing Bruce Sherwood and Davin Scherer, because they asked for
>this and used a similar implementation in VPython.  When this patch
>(or something not entirely unlike it) is accepted into Python 2.2,
>they will no longer have to maintain their own hacked Python.  

First let me say that VPython is something I use extensively in what I
do in Python, and consider a real contribution to Python - 
particularly in a CP4E context.  Thank you David and Bruce.

However, I believe it is simply inaccurate to say they have felt it
necessary to "maintain their own hacked Python".

What they do is what I - as a novice - understood to do to avoid
confusion over integer division issues when creating a facility
to script coordinate geometry -  cast coordinate arguments to a 
consistent numerical type, floats.  They apparently do it in their
C++ module.  I am using Numeric, my coordinates are arrays, with
a consistent typecode. No biggie. 

The VPython docs warn of the integer division issue, and
the "fix" - appropriately, enough.
 
>Floating Division

>Python performs integer division with truncation, 
>so that 3/4 is 0, not 0.75. 

but before giving the "fix" 

>You can write 3./4., which is 0.75 by the rules 
>of "floating-point" division.

the docs seem to go a bit out of their way to pick
their nit:

>This is inconvenient when doing scientific 
>computations, and can lead to hard-to-find 
>bugs in programs. 

In most contexts one concentrates on ones app,
documents its API, not its nits with the language
it has chosen to implement in.

My feature requests for VPython are on 
visual-python-dev, not in the docs of my app that
uses it.

But then the docs are also very public about its
nits with IDLE.

As much as I appreciate VPython, never quite
understood that.

ART