What? Pyramid doesn't have a debug code path, minus emitting some
log messages. Do you mean that the debugtoolbar is doing something to
the response?
On Tue, May 15, 2012 at 5:57 PM, Jonathan Vanasco jonat...@findmeon.com wrote:
I ran into an issue a few months ago regarding a NewResponse
subscriber and failing to catch errors (
https://groups.google.com/group/pylons-discuss/browse_thread/thread/54b5b3eb5e2ccfe/4e9a2abc09b9651f
)
As I prepare for a production release , my old code ( which i forgot
to remove ) started firing -- and I finally figured out what was
happening.
Because I had debugging turned on via 'development.ini', Pyramid was
catching the error response object from the app, and replacing it
with its own.
In a perfect world, the Pyramid debug system would let the original
response/request stuff somehow persist -- so code can be written that
works on production and development.
In a less perfect, though perfectly acceptable world, it would be
great if the debug event subscriber docs cross-referenced one
another with an alert/note box that simply states that the debug
system will 'overtake' the response object when turned on, and
subscribers that are designed to handle errors may not work as desired
when debugging is enabled.
--
You received this message because you are subscribed to the Google Groups
pylons-devel group.
To post to this group, send email to pylons-devel@googlegroups.com.
To unsubscribe from this group, send email to
pylons-devel+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/pylons-devel?hl=en.
--
You received this message because you are subscribed to the Google Groups
pylons-devel group.
To post to this group, send email to pylons-devel@googlegroups.com.
To unsubscribe from this group, send email to
pylons-devel+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/pylons-devel?hl=en.