On Tuesday, Feb 25, 2003, at 15:04 US/Eastern,
> 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
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.
I see that recent changes were made in logging/__init__.py to replace the
use of "apply(func, args)" with "func(*args)". Doesn't this cause "invalid
syntax" problems with 1.5.2? I explicitly coded using apply because I
thought it was needed for 1.5.2. There are a few places where I've eschewed
use of +=, for the same reason. Any chance we could change back to using
I got a problem report for Stackless today, that
it seems to leak with tracebacks.
After trying other Python versions, I found out
that this is a "feature" of Python and not related
to Stackless. The problem becomes only more visible,
since people are keeping thousands of threads alive.
Here the problem:
When an exception has been raised in a frame, and
it already is handled in an except clause, the
exception is not cleared out from tstate and also
stays alive in the frame object.
Only when the frame is left, eval_frame calls
which clear all these, breaking cycles.
Does this need to be so, and for what reason?
Would it be equivalent if I cleared error info
in the context of a finally: ?
If not, please give me advice how to solve this
problem. It exists in all long-running frames
which have seen exceptions.
Thanks a lot - chris
Christian Tismer :^) <mailto:firstname.lastname@example.org>
Mission Impossible 5oftware : Have a break! Take a ride on Python's
Johannes-Niemeyer-Weg 9a : *Starship* http://starship.python.net/
14109 Berlin : PGP key -> http://wwwkeys.pgp.net/
work +49 30 89 09 53 34 home +49 30 802 86 56 pager +49 173 24 18 776
PGP 0x57F3BF04 9064 F4E1 D754 C2FF 1619 305B C09C 5A3B 57F3 BF04
whom do you want to sponsor today? http://www.stackless.com/
I'm not a python-dev regular, so sorry if this is a FAQ. What's the status
of defining a syntax for function attributes (PEP 232)? I'm using __doc__
to carry metadata about methods right now, but would very much like to use
function attributes. However, without a specialized syntax, I'm stuck
doing things like
VeryLongMethodName.MetadataName = "foo"
which is fine if it's a one-off, but I'd like others to use the code, and
this isn't exactly a friendly mechanism. The proposals in the PEP would be
fine; I was thinking something like
"""this is the docstring"""
.this_is_a_function_attribute = 1
but that's just off the top of my head.
I'm happy to do some work writing a PEP if there's some consensus about
what syntax would be preferable.