Re: [Python-Dev] module extension search order - can it be changed?
On Tuesday, Feb 25, 2003, at 15:04 US/Eastern, python-dev-request@python.org wrote:
python23.zip is good for end users of programs written in Python, but not so good for Python programmers: AFAIK it won't show source lines in tracebacks for modules loaded from the zip file.
Speaking entirely from a point of ignorance, why are the source line #s not shown for frames that are implemented in modules loaded from zipimport? Assuming the ZIP archive could be exactly identical to what one might find in /usr/lib/python2.3/, the zip could contain all the py + pyc as found in the normal library? As such, it would be trivial for the developer to unzip the zip into-- for example-- /tmp/ for reference purposes. Assuming the developer has a copy of the 2.3 source lying around and has the zip with just the PYC, the lines numbers are still very useful. All things considered, I would think it would be highly desirable for the developer's Python development environment to be as much like a stock deployment environment as possible. Java made a grave mistake in this regard -- the whole class loader mechanism can cause massive problems-- very annoying and hard to debug problems-- when moving code from a development environment into deployment if the class loader that loads a particular class changes between the two environments. b.bum
Bill Bumgarner wrote:
On Tuesday, Feb 25, 2003, at 15:04 US/Eastern, python-dev-request@python.org wrote:
python23.zip is good for end users of programs written in Python, but not so good for Python programmers: AFAIK it won't show source lines in tracebacks for modules loaded from the zip file.
Speaking entirely from a point of ignorance, why are the source line #s not shown for frames that are implemented in modules loaded from zipimport?
Line *numbers* will be shown, the lines themselves won't.
Assuming the ZIP archive could be exactly identical to what one might find in /usr/lib/python2.3/, the zip could contain all the py + pyc as found in the normal library?
Yes, but currently the traceback logic that shows the offending line (the line itself, not the line number) depends on the source being in the actual file system. While this _could_ be fixed for zipimport, it's not entirely trivial. You should be able to find looong discussions about this topic in the python-dev archives... Also check PEP 302. Just
On Tuesday, Feb 25, 2003, at 15:32 US/Eastern, Just van Rossum wrote:
Line *numbers* will be shown, the lines themselves won't.
Oh, never mind. That's perfectly fine -- as long as the information is there, a cmd-l ### <cr> sequence is a small cost until one of us takes the time to figure out how to display the actual line from a zip... ... or maybe the answer is to look on the path and see if there is a corresponding source file somewhere? Obviously, this just went beyond python 2.3 discussion. b.bum
Speaking entirely from a point of ignorance, why are the source line #s not shown for frames that are implemented in modules loaded from zipimport?
Because the code printing the tracebacks doesn't know how to look inside a zip file. --Guido van Rossum (home page: http://www.python.org/~guido/)
Guido:
Someone:
Speaking entirely from a point of ignorance, why are the source line #s not shown for frames that are implemented in modules loaded from zipimport?
Because the code printing the tracebacks doesn't know how to look inside a zip file.
Maybe, if the source file can't be found, it could decompile the bytecode? Greg Ewing, Computer Science Dept, +--------------------------------------+ University of Canterbury, | A citizen of NewZealandCorp, a | Christchurch, New Zealand | wholly-owned subsidiary of USA Inc. | greg@cosc.canterbury.ac.nz +--------------------------------------+
Guido van Rossum <guido@python.org> writes:
Speaking entirely from a point of ignorance, why are the source line #s not shown for frames that are implemented in modules loaded from zipimport?
Because the code printing the tracebacks doesn't know how to look inside a zip file.
It Would Be Nice (tm) if the code that printed tracebacks could be made cleverer in some fashion. For instance, in a pyrepl session I have the source in the session's history and it would surely be nice if I could display it in tracebacks. Of course, I have no idea how to go about implementing this :-) Cheers, M. -- I never realized it before, but having looked that over I'm certain I'd rather have my eyes burned out by zombies with flaming dung sticks than work on a conscientious Unicode regex engine. -- Tim Peters, 3 Dec 1998
[Michael]
It Would Be Nice (tm) if the code that printed tracebacks could be made cleverer in some fashion.
I guess this could be a 2-stage thing: * Delegate the dumping of tracebacks in C code back to the traceback module. I guess that the existing code would need to remain if an error is raised printing it, but in general, traceback does a fine job. * Give linecache some additional smarts. Once we are back in Python land, the possibilities become vast. Mark.
"Mark Hammond" <mhammond@skippinet.com.au> writes:
[Michael]
It Would Be Nice (tm) if the code that printed tracebacks could be made cleverer in some fashion.
I guess this could be a 2-stage thing: * Delegate the dumping of tracebacks in C code back to the traceback module. I guess that the existing code would need to remain if an error is raised printing it, but in general, traceback does a fine job.
Yes, I've thought about this several times. I always get scared by the general copmlexity of it all, and bootstrapping issues.
* Give linecache some additional smarts. Once we are back in Python land, the possibilities become vast.
While we're at it, linecache's charming habit of occasionally giving out of date information is Pure Evil. Performance my arse, lying to the user is worse. Cheers, M. -- Hey, if I thought I was wrong, I'd change my mind. :) -- Grant Edwards, comp.lang.python
[Michael Hudson]
While we're at it, linecache's charming habit of occasionally giving out of date information is Pure Evil. Performance my arse, lying to the user is worse.
We don't use linecache often, and I've never tried comparative timing (with and without it). Offhand it's hard to believe that producing tracebacks benefits from it, or that inspect.py does. For 2.3b1, maybe we could change linecache.updatecache() to leave the cache empty and see whether anyone notices <0.7 wink>.
participants (7)
-
Bill Bumgarner -
Greg Ewing -
Guido van Rossum -
Just van Rossum -
Mark Hammond -
Michael Hudson -
Tim Peters