Changing to future division sitewide

[Michael Williams]

On Sun, 12 May 2002 13:16:49 +0100, Terry Reedy wrote:
>> 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 (/).

We could do this but I'm keen to remove *anything* that doesn't have to
be in. Although we are teaching *programming* and not *programming in
Python*, and as such a probably teaching more than a beginner Python 
programmer needs to know (e.g. How to manipulate arrays elementwise using
for loops rather than just using the built-in capabilities) this is one
thing we could do without explaining. Our students are from a very
mathematical background so will have no problem understanding the new
behaviour. They already have all the new concepts associated with procedural
programming to deal with so we thought we'd give them a break!

>> 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.

Indeed. Although there is virtually no installed code to break (I believe
Numeric is // vs / friendly although Gnuplot.py might show up some subtle
problems) tampering with the installed binaries is not something we'd want
to do.

>> 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.

Good idea. We expect very view students to actually use it from the command
line, although there is bound to be a few smart-arses who find it.

>> 2) running a module they've saved (or indeed any module)
> 
> Would all such modules be saved from idlefork?  If so, see below.

Yes.

>> 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.

I'll take this discussion over to the idle-dev mailing list.

-- 
Michael