We support co_consts for PyBytecode code objs. We may be able to extract them from Java bytecode - there's a regular layout to them - but it's more involved than just building up co_lnotab or some other line number structure by using visitLineNumber.

Creating the metadata as part of the compilation process is certainly an option for 2.5.1. Perhaps access to it could be done lazily so the only impact would be a small increase in the $py.class file size.

The bytecode offsets in co_lnotab seem useless for $py.class files.
Correct me if I'm wrong but they probably aren't too useful for .pyc
either outside of the dis module.

If we don't care about them, having the compiler tally the line
numbers into this lnotab structure would be about as easy as analyzing
the class w/ ASM after the fact. I'd just increment the byte offset by
1 for every entry. Then we could support co_lnotab on the code object.

This was the approach I took when I was looking at trace.py a few months ago, and it worked for simple scripts. The problem, at least for trace.py, was that it uses the co_consts attribute to find nested functions and some other odd places that code can hide. Here's the relevant snippet from trace.py:

def find_lines(code, strs):
"""Return lineno dict for all code objects reachable from code."""
# get all of the lineno information from the code of this scope level
linenos = find_lines_from_code(code, strs)

# and check the constants for references to other code objects
for c in code.co_consts:
if isinstance(c, types.CodeType):
# find another code object, so recurse into it
linenos.update(find_lines(c, strs))
return linenos

Implementing co_consts was looking like a much larger and uglier hack than co_lnotab, so I punted.
- moss