Changing to future division sitewide

[Terry Reedy]

"Michael Williams" <michael.williams at st-annes.oxford.ac.uk> wrote in
message news:ablhh9$ii04e$1 at ID-96223.news.dfncis.de...
> We are about to embark on a series of trials of the Python language
with
> a view to replacing Pascal as the teaching language here in the
> department of Physics at Oxford University [0].

Glad to read this.  I expect this will benefit students.

>We have a day (!) to teach the language so we are really keen on
using the
> new division that returns a mathematically intuitive result

However, to read other code, students must know of different solutions
to the int division problem, including Python's older/current one.

I would explain briefly as follows: Int division is inherently messy.
Properly speaking, the answer is a tuple -- with a choice as to
whether remainders are always positive or sometimes negative.  But we
want a single number, so we again have a choice -- drop the remainder
and keep integral part (which for negative answers can vary by one
depending on the remainer sign choice) -- or promote to rationals or
floats that allow fractional parts.  Python (new) gives you easy
access to three of these choices -- (floor, positive remainder) tuple
(divmod), floor (//), and float fraction (/).

> However, our students will be using idlefork to program (both
> intereactively and in stored modules). Is there any way we can get
the
> new division behaviour sitewide,

If you can compile an interpreter, I would suspect this would be
fairly easy to do.

>i.e. we would like the new behaviour in  the following situations:

However, that might be too universal.

> 1) typing python at a command prompt (alias "python" to
"python -Qnew"?)

How about py = python -Qnew instead, to keep this separate issue from
below.

> 2) running a module they've saved (or indeed any module)

Would all such modules be saved from idlefork?  If so, see below.

>    This might be problematic as it would presumably apply to all
modules
>    on the system which might break things--although this is a fresh
>    install of Python. All we have here is Python 2.2.1, Numeric,
>    Gnuplot.py (a Python wrapper of the Gnuplot program) and idlefork
>    (which is the development version of idle).

> 3) Someone using the interactive interpreter in idlefork

> Presumably this is going to involve doing more than one thing if it
> ieven possible. We could always tell our students to put "from
> __future__ import division" at the start of every program

I would aim at creating an 'idlepy' command which would bring up
python in -Qnew mode (assuming idlefork code itself is 'Qnew clean')
with a possibly-patched idlefork in mode in which *it* puts the magic
incantation at the start of every program.  Automate the repetitive.

I know nothing of idlefork at this time and do not know if it
currently has a switch to do this, but it certainly ought to.  I would
certainly like a version that would do so.  I suspect others would
also.

> without explaining it, but that's the kind a black magic we hoped to
avoid by
> using Python rather than, say, C.

The current transitional reality is messy.  (I would personally prefer
faster to slower, but there was a lot of pressure toward slowness.)
Just explain that Python is in transition from worse choice to better
choice (among those discussed above) and hence the temporary kludge.

Terry J. Reedy