[Python-Dev] Changing the Division Operator -- PEP 238, rev 1.12

[Michael Hudson]

Guido van Rossum <guido@zope.com> writes:

> > Not directly relavent to the PEP, but...
> > 
> > Guido van Rossum <guido@zope.com> writes:
> > 
> > >     Q. What about code compiled by the codeop module?
> > > 
> > >     A. Alas, this will always use the default semantics (set by the -D
> > >        command line option).  This is a general problem with the
> > >        future statement; PEP 236[4] lists it as an unresolved
> > >        problem.  You could have your own clone of codeop.py that
> > >        includes a future division statement, but that's not a general
> > >        solution.
> > 
> > Did you look at my Nasty Hack(tm) to bodge around this?  It's at 
> > 
> >     http://starship.python.net/crew/mwh/hacks/codeop-hack.diff
> > 
> > if you haven't.  I'm not sure it will work with what you're planning
> > for division, but it works for generators (and worked for nested
> > scopes when that was relavent).
> 
> Ouch.  Nasty.  Hat off to you for thinking of this!

I'll choose to take this as a positive remoark :-)

> > There are a host of saner ways round this, of course - like adding an
> > optional "flags" argument to compile, for instance.
> 
> We'll have to keep that in mind.

Here's a fairly short pre-PEP on the issue.  If I haven't made any
gross editorial blunders, can Barry give it a number and check the
sucker in?

PEP: XXXX
Title: Supporting __future__ statements in simulated shells
Version: $Version:$
Author: Michael Hudson <mwh@python.net>
Status: Draft
Type: Standards Track
Requires: 0236
Created: 30-Jul-2001
Python-Version: 2.2
Post-History: 

Abstract

    As noted in PEP 263, there is no clear way for "simulated
    interactive shells" to simulate the behaviour of __future__
    statements in "real" interactive shells, i.e. have __future__
    statements' effects last the life of the shell.

    This short PEP proposes to make this possible by adding an
    optional fourth argument to the builtin function "compile" and
    adding machinery to the standard library modules "codeop" and
    "code" to make the construction of such shells easy.

Specification

    I propose adding a fourth, optional, "flags" argument to the
    builtin "compile" function.  If this argument is omitted, there
    will be no change in behaviour from that of Python 2.1.

    If it is present it is expected to be an integer, representing
    various possible compile time options as a bitfield.  The
    bitfields will have the same values as the PyCF_* flags #defined
    in Include/pythonrun.h (at the time of writing there are only two
    - PyCF_NESTED_SCOPES and PyCF_GENERATORS).  These are currently
    not exposed to Python, so I propose adding them to codeop.py
    (because it's already here, basically).

    XXX Should the supplied flags be or-ed with the flags of the
    calling frame, or do we override them?  I'm for the former,
    slightly.

    I also propose adding a pair of classes to the standard library
    module codeop.

    One - probably called Compile - will sport a __call__ method which
    will act much like the builtin "compile" of 2.1 with the
    difference that after it has compiled a __future__ statement, it
    "remembers" it and compiles all subsequent code with the
    __future__ options in effect.

    It will do this by examining the co_flags field of any code object
    it returns, which in turn means writing and maintaining a Python
    version of the function PyEval_MergeCompilerFlags found in
    Python/ceval.c.

    Objects of the other class added to codeop - probably called
    CommandCompiler or somesuch - will do the job of the existing
    codeop.compile_command function, but in a __future__-aware way.

    Finally, I propose to modify the class InteractiveInterpreter in
    the standard library module code to use a CommandCompiler to
    emulate still more closely the behaviour of the default Python
    shell.

Backward Compatibility

    Should be very few or none; the changes to compile will make no
    difference to existing code, nor will adding new functions or
    classes to codeop.  Exisiting code using
    code.InteractiveInterpreter may change in behaviour, but only for
    the better in that the "real" Python shell will be being better
    impersonated.

Forward Compatibility

    codeop will require very mild tweaking as each new __future__
    statement is added.  Such events will hopefully be very rare, so
    such a burden is unlikely to cause significant pain.

Implementation

    None yet; none of the above should be at all hard.  If this draft
    is well received, I'll upload a patch to sf "soon" and point to it
    here.

Copyright

    This document has been placed in the public domain.


-- 
  ARTHUR:  The ravenours bugblatter beast of Traal ... is it safe?
    FORD:  Oh yes, it's perfectly safe ... it's just us who are in 
           trouble.
                    -- The Hitch-Hikers Guide to the Galaxy, Episode 6