On Feb 8, 11:54 am, Christian Boos <[EMAIL PROTECTED]> wrote: > The last referrer is most of the time a dict object which looks like the > session, but is not the session - I've modified the Session so that it's > no longer a dict itself but an object delegating its dict like methods > to a self._dict dictionary. Even that new _dict field shows up as a key > in this dict-like session, so I'm sure the new code is picked (btw, I > did this change because ofhttp://bugs.python.org/issue1469629). But it > happened a few time that this third object was an unrelated <Request > "..../trac.css"> object, and sometimes another list with a huge pile of > crap inside (not the live objects list). Weird. Not to mention that this > dict doesn't appear to even contain an entry for 'data'...
I was looking at the Trac Pygments code yesterday 'by accident' as I noticed trac.mimeview.pygments.py implements its own request handler to return the (default selected) trac.css stylesheet extract. It responds to /pygments/trac.css, and does this in a very 'direct' manner - it raises a straight Exception, and it writes its own headers and response directly to the request object from the request handler. I have done no further review of this, it just rang a bell seeing that '.../trac.css' in your findings. With your test scripts it would be easy to verify the soundness of this by disabling the pygments module when running your tests. :::simon https://www.coderesort.com --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Trac Development" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/trac-dev?hl=en -~----------~----~----~----~------~----~------~--~---
