On 9/6/07, Marcin Kasperski <[EMAIL PROTECTED]> wrote: > > > 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.
That's cool. It didn't exist the last time I tried Twisted. There was talk about how Python 2.5's generator enhancements could allow inlined callbacks within a function. > > 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. There's also your original reason. Somebody might have a Twisted application that needs a web interface, and they'd like to write it in a "normal" full-featured framework with integrated Javascript/template/widget support rather than a limited designer-unfriendly framework. > > 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. It's important in any case for Twisted to be able to run WSGI apps, and for Pylons to be compatible with Twisted even if it has to be an inefficient threaded way. Interoperability is always a good thing, for reasons that may become apparent only later when you need it. > > 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). That's a good idea, and doable. Use Pylons as a starting point, take out what you don't need or is difficult to port, and see if you can find a subset that works well with Twisted. Jython has a subset of CPython's features and adds its own, but it's close enough that you can write apps that run in both. Twisted Pylons has a nice ring to it and suggests a delightful logo of a pylon twisted from a windstorm. (The kind Sid from Toy Story would make.) -- Mike Orr <[EMAIL PROTECTED]> --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
