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. >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.
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4