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

[Michael Hudson]

"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