[Patches] [ python-Patches-449043 ] supporting __future__ in simulated shells
noreply@sourceforge.net
noreply@sourceforge.net
Fri, 17 Aug 2001 15:21:14 -0700
Patches item #449043, was opened at 2001-08-08 02:05
You can respond by visiting:
http://sourceforge.net/tracker/?func=detail&atid=305470&aid=449043&group_id=5470
Category: library
Group: None
Status: Open
>Resolution: Accepted
Priority: 5
Submitted By: Michael Hudson (mwh)
Assigned to: Fred L. Drake, Jr. (fdrake)
Summary: supporting __future__ in simulated shells
Initial Comment:
This implements the short PEP I posted to python-dev last week.
It doesn't do docs, and it uses the disputed bitfield interface to compile(), so it should be considered a first cut.
----------------------------------------------------------------------
>Comment By: Tim Peters (tim_one)
Date: 2001-08-17 15:21
Message:
Logged In: YES
user_id=31435
Just changed Resolution to Accepted, but should remain Open
until the doc patch is processed too.
----------------------------------------------------------------------
Comment By: Tim Peters (tim_one)
Date: 2001-08-17 15:17
Message:
Logged In: YES
user_id=31435
Reassigned to Fred for the doc patch (and I deleted the
other attachments).
Checked in the rest (repair of PyEval_MergeCompilerFlags
came in between):
Lib/code.py; new revision: 1.17
Lib/codeop.py; new revision: 1.5
Misc/NEWS; new revision: 1.209
Python/bltinmodule.c; new revision: 2.228
This seems solid now so far as it goes, and, e.g., IDLE
now "does the right thing" for __future__ statements by
magic. I still need to teach doctest how to exploit it.
Testing got artificially confused by a different bug (that
new division doesn't propagate to 'eval'), so I'm going to
fix that bug next and then get back to stressing this.
----------------------------------------------------------------------
Comment By: Tim Peters (tim_one)
Date: 2001-08-17 12:51
Message:
Logged In: YES
user_id=31435
I'm going to do this in pieces.
First checked in a reworked version of __future__.py, and
added verification to test___future__.py:
Lib/__future__.py; new revision: 1.9
Lib/test/test___future__.py; new revision: 1.3
----------------------------------------------------------------------
Comment By: Tim Peters (tim_one)
Date: 2001-08-17 11:30
Message:
Logged In: YES
user_id=31435
Testing turned up bugs, and I'm fixing them. Gross
example: the anonymous hex constant attached to
nested_scopes in the patched __future__.py was actually the
constant for the CO_GENERATOR flag, not the constant for
the correct CO_NESTED flag. I've reworked the code to
repair that, but also to make it harder for that to happen
again; ideally, Python-level CO_xxx flags should be
exported by a builtin C module, and so that Jeremy's
pyassem.py can use them too (it's got its own hardcoded (re)
definitions), but I'm not being that ambitious. The
simplest thing that could possibly work is that a global
search on, e.g., CO_NESTED, find its use and value in
__future__.py too, so that's what I'm settling for.
I'll check it in when it all works. That won't be this
instant, but will certainly be today.
----------------------------------------------------------------------
Comment By: Guido van Rossum (gvanrossum)
Date: 2001-08-17 03:59
Message:
Logged In: YES
user_id=6380
What's stopping this from being checked in?
----------------------------------------------------------------------
Comment By: Tim Peters (tim_one)
Date: 2001-08-16 22:34
Message:
Logged In: YES
user_id=31435
This is looking good! I think I know how to get doctest to
use it too (to emulate the future settings of the
doctest'ed module) -- which would remove an unpleasant wart
in current CVS (doctest imports generators from __future__
now, despite that it doesn't use any generators; else
test_generators.py would fail).
Leaving assigned to me since Michael's on vacation now.
----------------------------------------------------------------------
Comment By: Michael Hudson (mwh)
Date: 2001-08-14 14:27
Message:
Logged In: YES
user_id=6656
I think this latest version actually compiles (ahem).
As far as I'm concerned, the coding is now done.
Also attach a first cut at some doc updates. Fred will definitely
need to fiddle these to get them to compile (there's no latex here on
the starship).
I should probably do some test cases.. later.
----------------------------------------------------------------------
Comment By: Michael Hudson (mwh)
Date: 2001-08-10 15:41
Message:
Logged In: YES
user_id=6656
Here's another one. This copes with the changes Jeremy just made to feature flag handling, rejigs some docstrings, adds the dont_inherit argument to compile() and actually makes the changes to codeop.py that were described in the PEP (a new version of which will be checked in shortly).
No rest for the wicked: more docs and some tests still needed.
----------------------------------------------------------------------
Comment By: Tim Peters (tim_one)
Date: 2001-08-09 22:01
Message:
Logged In: YES
user_id=31435
Assigned to me. WIll look more closely later. Things that
struck the eye at once:
+ _Feature.matches needs a docstring.
+ "<>" is deprecated; use "!=".
+ I think we need a way not to "or" in the caller's flags
too; but you also think that, so this shouldn't be hard for
us to reach agreement on <wink>.
----------------------------------------------------------------------
Comment By: Michael Hudson (mwh)
Date: 2001-08-09 15:26
Message:
Logged In: YES
user_id=6656
New version.
This one attaches knowledge of code flag and compile time bits to the
_Feature objects in Lib/__future__.py.
It also rewrites the docstrings in codeop.py; still pending: latex docs,
updates to my PEP and possibly 236 (the __future__ one), sanity checking
the arguments to __builtin__.compile().
----------------------------------------------------------------------
Comment By: Guido van Rossum (gvanrossum)
Date: 2001-08-08 07:26
Message:
Logged In: YES
user_id=6380
Nice! Two questions:
1. Why the refactoring of codeop.py?
2. Shouldn't the built-in compile() do a sanity check on the
flags it accepts?
----------------------------------------------------------------------
You can respond by visiting:
http://sourceforge.net/tracker/?func=detail&atid=305470&aid=449043&group_id=5470