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
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4