[Python-bugs-list] [ python-Bugs-597919 ] compiler package and SET_LINENO
noreply@sourceforge.net
noreply@sourceforge.net
Fri, 01 Nov 2002 12:18:41 -0800
Bugs item #597919, was opened at 2002-08-20 15:51
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=597919&group_id=5470
Category: Python Library
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Fred L. Drake, Jr. (fdrake)
Assigned to: Jeremy Hylton (jhylton)
Summary: compiler package and SET_LINENO
Initial Comment:
The compiler package should not issue SET_LINENO
instructions any more. Running the Zope 2.7 test suite
produces this traceback:
Traceback (most recent call last):
File "test.py", line 433, in ?
process_args()
File "test.py", line 397, in process_args
bad = main(module_filter, test_filter)
File "test.py", line 308, in main
runner(files, test_filter, debug)
File "test.py", line 275, in runner
s = get_suite(file)
File "test.py", line 230, in get_suite
mod = package_import(modname)
File "test.py", line 211, in package_import
mod = __import__(modname)
File
"/home/fdrake/projects/Zope/Zope2.7/lib/python/RestrictedPython/tests/testRestrictions.py",
line 64, in ?
create_rmodule()
File
"/home/fdrake/projects/Zope/Zope2.7/lib/python/RestrictedPython/tests/testRestrictions.py",
line 55, in create_rmodule
code = compile_restricted(source, fn, 'exec')
File
"/home/fdrake/projects/Zope/Zope2.7/lib/python/RestrictedPython/RCompile.py",
line 147, in compile_restricted
gen.compile()
File
"/usr/local/lib/python2.3/compiler/pycodegen.py", line
123, in compile
self.code = gen.getCode()
File
"/usr/local/lib/python2.3/compiler/pycodegen.py", line
252, in getCode
return self.graph.getCode()
File "/usr/local/lib/python2.3/compiler/pyassem.py",
line 378, in getCode
self.convertArgs()
File "/usr/local/lib/python2.3/compiler/pyassem.py",
line 484, in convertArgs
self.insts[i] = opname, conv(self, oparg)
File "/usr/local/lib/python2.3/compiler/pyassem.py",
line 520, in _convert_LOAD_CONST
arg = arg.getCode()
File
"/usr/local/lib/python2.3/compiler/pycodegen.py", line
252, in getCode
return self.graph.getCode()
File "/usr/local/lib/python2.3/compiler/pyassem.py",
line 380, in getCode
self.makeByteCode()
File "/usr/local/lib/python2.3/compiler/pyassem.py",
line 585, in makeByteCode
lnotab.addCode(self.opnum[opname], lo, hi)
KeyError: SET_LINENO
----------------------------------------------------------------------
Comment By: Bill Noon (bnoon)
Date: 2002-11-01 15:18
Message:
Logged In: YES
user_id=298547
I just used the patch to fix problems with Quixote. Seems
to have done the trick.
----------------------------------------------------------------------
Comment By: Michael Hudson (mwh)
Date: 2002-10-10 05:38
Message:
Logged In: YES
user_id=6656
Ah good. Will wait for your comments.
----------------------------------------------------------------------
Comment By: Jeremy Hylton (jhylton)
Date: 2002-10-09 18:27
Message:
Logged In: YES
user_id=31392
I'm listening, but it's going in one ear and out the other.
I hope to have time for this later in the week.
----------------------------------------------------------------------
Comment By: Michael Hudson (mwh)
Date: 2002-10-09 08:54
Message:
Logged In: YES
user_id=6656
Here's a patch that lets me compile the standard library and
test suite with the compiler package and then run the test
suite successfully.
It does... oh, lots and lots of stuff. Is anyone listening?
----------------------------------------------------------------------
Comment By: Michael Hudson (mwh)
Date: 2002-10-03 06:08
Message:
Logged In: YES
user_id=6656
Here's a patch.
Remarkably, it's just a one line patch to work around the
SET_LINENO breakage.
Other changes:
* open the file for compiling in universal newlines mode.
* always write the mtime to a .pyc little-endian-wise
(2.2.2 candidate)
* it's YIELD_VALUE, not YIELD_STMT (2.2.2 candidate)
* bodge the parsermodule to return the encoding along with the
encoding_decl non-terminal (this is pretty icky!)
* let transformer cope with new 'testlist1' non-terminal
* have transformer pick up the encoding declaration
Still to do is using the encoding declaration to decode
string literals. I think there should be an accessible from
Python function to do this -- I really don't want to have to
translate compile.c:parsestr into Python!
----------------------------------------------------------------------
Comment By: Michael Hudson (mwh)
Date: 2002-10-03 05:38
Message:
Logged In: YES
user_id=6656
Hmm. I think I can fix the SET_LINENO breakage, but the
compiler package is shafted in various other ways, notably
by PEP 263.
Fixing this seems to require a bewildering array of patches
-- to symbol.py, to parsermodule, to token.py...
I also found a couple of bugs, which I'll fix. Some of
these should probably go into 2.2.2, too.
----------------------------------------------------------------------
Comment By: Michael Hudson (mwh)
Date: 2002-08-31 11:33
Message:
Logged In: YES
user_id=6656
I'm about to go away for a week, so if you want my help
you'll probably have to wait until I get back.
----------------------------------------------------------------------
Comment By: Michael Hudson (mwh)
Date: 2002-08-23 05:39
Message:
Logged In: YES
user_id=6656
Believe it or not, I'd actually got that far myself <wink>.
If it'd been that easy, the changes would have been part of
my original SET_LINENO removal patch.
I guess the first question to answer is where does the
lnotab live during compilation? In the CodeGenerator? Then
logic has to move from PyFlowGraph.makeByteCode to
CodeGenerator.set_lineno.
----------------------------------------------------------------------
Comment By: Jeremy Hylton (jhylton)
Date: 2002-08-22 12:39
Message:
Logged In: YES
user_id=31392
A grep for SET_LINENO in the compiler package source will be
somewhat helpful. There are very few places that actually
emit the instructions. I thought they could just be
removed, but the lnotab is generated *from* the SET_LINENO
instructions. So we need to come up with a different way to
generate the lnotab.
----------------------------------------------------------------------
Comment By: Michael Hudson (mwh)
Date: 2002-08-21 05:08
Message:
Logged In: YES
user_id=6656
This is my fault, obviously.
I'm prepared to do some legwork to fix this problem, but don't really understand the code well enough to judge the best approach.
----------------------------------------------------------------------
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=597919&group_id=5470