On 11/9/06, Graham Dumpleton [EMAIL PROTECTED] wrote:
I would have assumed that the code is safe as the calling Python stack
frame still holds a reference count on any objects passed to you and
since it is waiting for you to finish, even if in an allow threads state,
there shouldn't be anyway
I know this isn't about mod_python, but I can think of nobody better
qualified to answer this question than mod_python developers.
If in a C function you release the GIl using begin/end allow threads,
does it change your responsibilites with regard to the reference
counts on the input
On 10/27/06, Graham Dumpleton [EMAIL PROTECTED] wrote:
Jim sent this to me when the python-dev list was down for maintenance.
Can anyone with Python 2.5 who knows something about function internals
enlighten us about what may have changed here. Previously the names
of nested functions appeared
On 10/27/06, Graham Dumpleton [EMAIL PROTECTED] wrote:
Unless they have really screwed things around, co_varnames is
specifically
for function argument names and is unlikely to contained nested constant
names. If it did, then I would expect a lot of the publisher code to
break in
other ways as
I know we have talked a bit before about providing a means of allowing people
to return custom error pages and I haven't forgotten that. The cleanup of the
code and working out what the report error function should take in the way of
arguments is a first step to seeing how the ability to override
On 10/8/06, solo turn [EMAIL PROTECTED] wrote:
when does mod_python support python-2.5?
I'm running mod_python on 2.5 for more than two weeks now without any
problems that I've been aware of. Grab the trunk version from the
subversion and have fun.
-Dan
I get the following linker errors when trying to compile mod_python as
fetched from the svn tonight.
mod_python error LNK2019: unresolved external symbol
__imp__MpFinfo_FromFinfo referenced in function _getreq_rec_fi
mod_python error LNK2019: unresolved external symbol
__imp__MpFinfo_New
On 8/27/06, Graham Dumpleton [EMAIL PROTECTED] wrote:
Hmmm, I didn't think you were wanting to go to that level of customisation.
I've only mocked up the idea, it would probably be between 5-8 hours
work to finish it as described.
If you do, I would suggest that we add a new directive to
The new importer gets my vote.
I've been using it for a while now in my development servers and it
works great. I've not discovered any bugs. I've verified it with
PythonAutoReload and PythonDebug in any combination of On and Off. For
a complex hierarchy of python files in with both set to off,
I grew tired of scrolling down through the very long tracbacks to get
to the actual error, so I wrote a function that lets me skip
everything up to my handler function. While I was at it I figured I
may as well highlight the things I want to see to make the tracebacks
easier to read. When I was
I'll agree that mod_python 3.3 tracebacks are perhaps longer than they
need to be given that I factored out various stuff into some functions
so as to be able to reuse it across connection, handler and filter dispatch.
I also like the idea of using colour to highlight important stuff.
Thus,
On 8/12/06, Graham Dumpleton [EMAIL PROTECTED] wrote:
On 13/08/2006, at 3:43 AM, Dan Eloff wrote:
I had some modules with circular imports and I only discovered that
this was a problem when I tried to discover why my modules were being
reimported constantly. I would suggest that this code
I had some modules with circular imports and I only discovered that
this was a problem when I tried to discover why my modules were being
reimported constantly. I would suggest that this code be changed to
log an error that explicitly tells you that there's a circular import,
and what the
Probably best to err on the side of caution. I don't mind the way it
works now, and I'd rather have that than an unpredictable bug that
takes frustrating hour upon hour to solve.
-Dan
On 5/11/06, Graham Dumpleton [EMAIL PROTECTED] wrote:
On 12/05/2006, at 3:52 AM, Dan Eloff wrote:
On 5/10
14 matches
Mail list logo
