> plus Twisted's Deferreds and callbacks are enough to
> make many other programmers run screaming from the room.
Heya, they are beautiful ;-) Especially with the @deferredGenerator
and @inlineCallback syntaxes. This is pretty:
@deferredGenerator
def thingummy():
thing = waitForDeferred(makeSomeRequestResultingInDeferred())
yield thing
# yeah, other task could run now
thing = thing.getResult()
print thing #the result! hoorj!
and this is even prettier (but require python 2.5):
@inlineCallbacks
def thingummy():
thing = yield makeSomeRequestResultingInDeferred()
print thing #the result! hoorj!
So, one ends just writing 'normal' functions, but putting yields
where it makes sense to cooperate.
> But given that the other megaframeworks have not yet been ported to
> Twisted, we could be the first!
Well, maybe some argument why such works can make some sense. Thanks
to the single-process, single-stack model Twisted behaves very well in
tight memory requirements. Well, machines tend to be faster and
greater today but there are embedded systems and ... what is of more
importance for pylons&co, there are more and more people hosting web
applications on VPS-s. Where one can find himself having 64MB or 96MB
RAM, for example. The same context makes it possibly useful to
colocate a few apps in single process.
>
> Twisted Web 1 had a WSGI server, but it was buggy and wasn't ported to
> Twisted Web 2. That would be the first hurdle. Searching for "wsgi"
> at twistedmatrix.com brings several results suggesting that WSGI
> support is still in pre-alpha state.(...)
Well, I've heard of people using twisted WSGI succesfully, but the
main problem is that this WSGI by itself is not very twisted-ish - it
just runs deferToThread, so the normal multithreaded WSGI
implementation arises.
> (...cut longer technical discussion...)
This more or less confirms, that there are plenty of non-trivial
problems to solve.
> Twisted apps use a
> special DBAPI wrapper
> (http://twistedmatrix.com/projects/core/documentation/howto/enterprise.html).
> Given its callback-style queries and separate connection pool, I don't
> see how you'd integrate it with SQLAlchemy.
Here there were some attempts. I haven't used sAsync yet, but it may
be promising: http://foss.eepatents.com/sAsync
> So it definitely would be much easier to get Twisted WSGI working so
> that it can run a non-Twisted application in a thread, (...)
Well, that is true, but it also defeats the main purpose to some
degree. But ... I am not complaining, I was just curious about
the state of the things.
> The alternative, making Pylons and its dependencies into a
> non-blocking Twisted application, would be much more work, and it
> may not be possible without making incompatible changes that would
> break Pylons' normal usage.
After reading your post, and some reconsideration, I turn to the
opinion that it need not make sense to 'port pylons to twisted'
directly. Better idea may be to try to merge parts of twisted.web2
with selected components from pylons (for example, to use routes for
url resolution, share some layout and/or configuration ideas).
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"pylons-discuss" 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/pylons-discuss?hl=en
-~----------~----~----~----~------~----~------~--~---
