Well, as web3py is going to be python3-based, it may use Tulip in it's module-form... But perhaps you are right about not rushing it, perhaps web4py would be a better target... :) (or rather, web3py 2.x...)
But my point is that PEP380 in Python 3.3 is already a very solid basis for building event-loop kind of web-framework with non-blocking-IO that are single-threaded... The current recommendation for production-deployment of web2py is Apache, which (as I understand it) has it's mod_wsgi spawn a python-thread for each request. This has all the performance-penalties mentioned in the first video I posted (relating to the GIL), in addition to the famous 10K barrier of machine resource and system-thread-limits. Saying that Rocket and Cherrypy are the main focus, is irrelevant. It may stay like that for educational/experimentation use-cases, but it has no relevance to production-deployments. But I think the main thing that bugs me is that whenever I start talking about asunc and non-blocking-I/O in this group, everybody immediately assume I am just talking about either front-end web-serving, or back-end database-connections... I am considering I/O as also being ipc or even in-proc communications - having web2py able to communicate with other server-side services, and/or different connection-sessions within itself for "push" enabled "collaborative" use-cases (whether being based on WS, SSE, LP. or any other...). I am talking about transforming web2py's internals to being async/event-loop capable, within a single-threaded deployment story. It is frustrating to me that people are not getting this message... This IS the direction that web-development is moving into around the world, and if web3py will not keep up with this trend, it may not even see the light of day before being left in the dust of history... And I would deem that a very sad day for all of us... Web2py is keen on backwards-compatibility - web3py is not - so it is an opportunity for restructuring some internals and joining web3py with the rest of the second-decade of the 21's century... (if not spear-heading it...) On Tue, Apr 16, 2013 at 7:45 AM, Niphlod <niph...@gmail.com> wrote: > web2(3)py builds "on-top" of things: taking a not-finished library as > something that can change from time to time basically leads to "if tulip > dies so does web2(3)py". So, until it's committed to python stable, noone > would pickup that as a base reference to build a framework. > > Benoitc is the author of gunicorn, that works yet and pretty awesomely > without hiccups. > > As things stand, there are a very few places in which web2(3)py needs > improvement to support "the async way". > All the blockings are circumventable with web2(3)py as it is running > inside an evented environment, and leveraging specific "async-friendly" > drivers for the db interaction. > > If the issue is "choose a different standard webserver than rocket", we > tried not so long ago to review all the possible options, but at the time > being there's no python webserver capable of doing everything cherrypy or > rocket do, so it would cripple a lot of installation environments. > That being said, if something that builds on top of tulip comes up and > supports wsgi, it can be easily added to anyserver.py. > > > -- > > --- > You received this message because you are subscribed to a topic in the > Google Groups "web2py-users" group. > To unsubscribe from this topic, visit > https://groups.google.com/d/topic/web2py/ExLCcJzS79k/unsubscribe?hl=en. > To unsubscribe from this group and all its topics, send an email to > web2py+unsubscr...@googlegroups.com. > For more options, visit https://groups.google.com/groups/opt_out. > > > -- --- You received this message because you are subscribed to the Google Groups "web2py-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to web2py+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
