[Python-Dev] Simplify lnotab? (AST branch update)
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.
> 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
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