> > The problem with using Pylons as a web-framework on top of it comes
> > from the fact that some parts of Pylons (beaker, routes) rely on the
> > python threading libraries for things like locking and thread locals.
> > Thus there is a hard coded assumption that pylons apps will always be
> > deployed in a threading based WSGI Server.
>
> > Instead of trying to monkey patch Pylons or the standard python
> > threading libraries with my equivalents (TaskLocal), would it not be
> > nice if the threading stuff could be factored out of Pylons and that
> > it would be up to the 'container / WSGIServer' to provide these
> > services trough some well defined API?
>
> The WSGI server already provides a per-request environment ("environ")
> and that's all that's needed.
> It's very unfortunetate that Pylons uses ThreadLocal storage, when it
> even creates object instances per-request.Now, it would be interesting to know what parts of Pylons are using ThreadLocal and what don't. Does Beaker use it, does Routes use it? --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
