[Python-Dev] Simplify lnotab? (AST branch update) (original) (raw)

Michael Hudson mwh at python.net
Fri Oct 14 17:53:17 CEST 2005

"Phillip J. Eby" <pje at telecommunity.com> writes:

At 09:23 AM 10/14/2005 +0100, Michael Hudson wrote:

"Phillip J. Eby" <pje at telecommunity.com> writes:

> Even better if the lines for a particular piece of code don't have > to all come from the same file. This seems fairly esoteric to me. Why do you need it? Compilers that inline function calls, but want the code to still be debuggable. AOP tools that weave bytecode. Overloaded functions implemented by combining bytecode.

Err...

Okay, those are fairly esoteric use cases, I admit. :) However, PyPy already has some inlining capability in its optimizer, so it's not all that crazy of an idea that Python in general will need it.

Um. Well, I still think it's pretty crazy.

I can think of two uses for lnotab information: printing source lines and locating source lines on the filesystem. For both, I think I'd rather see some kind of defined protocol (methods on the code object, maybe?) rather than inventing some kind of insane too-general-for-the-common-case data structure. Certainly a protocol would be nice; right now one is forced to interpret the data structure directly. Being able to say, "give me the file and line number for a given byte offset" would be handy in any case. However, since you can't subclass code objects, the capability would have to be part of the core.

Clearly, but any changes to co_lnotab would have to be part of the core too. Let's not make a complicated situation worse.

Something I didn't say was that a protocol like this would also let us remove the horrors of functions like inspect.getsourcelines() (see SF bugs passim).

Cheers, mwh

-- There's an aura of unholy black magic about CLISP. It works, but I have no idea how it does it. I suspect there's a goat involved somewhere. -- Johann Hibschman, comp.lang.scheme

More information about the Python-Dev mailing list