5 ms·

1) What makes uvloop which is based on libuv 2x faster than node.js which is also based on libuv? 2) Can uvloop be used with frameworks like flask or django?

1) What makes uvloop which is based on libuv 2x faster than node.js which is also based on libuv? 2) Can uvloop be used with frameworks like flask or django? 3) gevent uses monkey patching to turn blocking libraries such as DB drivers non-blocking, does uvloop do anything similar? If not how does it work with blocking libraries?

1st1 10y ago
1) I don't know :( I've answered a similar question in this thread with a couple of guesses. 2) No, they have a different architecture. Although I heard that there is a project to integrate asyncio into django to get websockets and http/2. 3) asyncio/uvloop require you to use explicit async/await. So, unfortunately, the existing networking code that isn't built for asyncio can't be reused. On the bright side, there are so many asyncio DB drivers and other modules now!
- sandGorgon 10y ago
  > 2) No, they have a different architecture Having a web framework (a next generation Flask if you will) built ground up with concurrency is the missing key. I have used Flask for many years, but this is the right time to introduce a new framework - because of the internal restructuring and slowdown of Flask's maintainers (and I say this with the utmost respect). If you are keen, this has the potential to be the killer application for Python 3.
  - 1st1 10y ago
    I'm actually thinking about writing such a framework :) I'll call it "spin".
    - happytrails 10y ago
      sounds good! Go forth!
    - sandGorgon 10y ago
      You totally should. I think people are hungry for a next gen async web framework... And if it leverages Python 3, then so much the better. Flask cannot go here even if it wants because its core philosophy is to be WSGI compliant. You don't necessarily have to adhere to that. Just one point, please make sure you have designed DB access as a core part of your framework (e.g. [1]). Too many frameworks discount database interaction until it's too late. Oh and please please choose your name so that it doesn't conflict on Google search. http://www.spinframework.org http://www.spinframework.org [1] http://initd.org/psycopg/docs/advanced.html#async-support http://initd.org/psycopg/docs/advanced.html#async-support vs https://github.com/chtd/psycopg2cffi https://github.com/chtd/psycopg2cffi
      - jagger27 10y ago
        Since spin is conflicting, may I suggest spyn? Gets that nice little Python 'py' in there.
        hasenj 10y ago
        Can also be read as "spine".
      - alexchamberlain 10y ago
        If such a framework was built around asyncio, do we really need yet another database layer? 1 of the best things about Flask is it doesn't reinvent the wheel.
        sandGorgon 10y ago
        It's not so much as another dB layer, but some async compatible dB layer. Most database libraries don't play very well with non blocking code. In fact nodejs dB libraries were specifically designed for this. Building async frameworks is not trivial - http://initd.org/psycopg/docs/advanced.html#async-support http://initd.org/psycopg/docs/advanced.html#async-support
      - michaelmcmillan 10y ago
    - continuations 10y ago
      Go for it! An async python web framework with the speed of Go and the ecosystem of python would be a killer app.
      - sametmax 10y ago
        We are actually working on a project like this with Tygs (https://github.com/Tygs/tygs https://github.com/Tygs/tygs, which will use crossbar.io), and right now it's taking ages just to get the app life cycle right. Indeed, we want to make it very easy to use, especially a clean/discoverable API, simple debugging, clear errors, etc. Which is the stuff async frameworks are not good at, and an incredible added value. It's a lot more work we initially thought. When you are doing async, you now think, not with a sequence of actions ordered in time, but with events. So for your framework to be usable, you must provide hooks to: - do something at init - register a component - do something when a component is registered - do something once it's ready - do something when there is an error - do something when it shuts down With minimum boiler plate, and maximum clear error handling when the user try to do it at the wrong time or in the wrong way. But, we learned while coding the project that, with asyncio, exceptions in coroutine don't break the event look (except KeyboardInterrupt which is a weird hybrid) while exceptions from the loop do break it. Plus you have to make a nice setup, which auto starts the event loop with good default so that people don't have to think about it for simple apps. But it must be overridable, and handle the case where your framework is embeded inside an already started event loop, and make it easy to do so. It's one of the strong point of gevent: you don't have to think about it. With asycio/twisted, you have the benefit a explicit process switch and parallelism, but you need to pay the price with verbosity and complexity. We try to create a balance, and it's turns out to be harder than expected. Then you have to make clear error reporting, especially iron the implementation mixing Task, Futures, coroutine functions and coroutines. Provide helpers so that common scheduling is done easily... And you haven't even talked about HTTP yet. This is just proper asyncio management. This is why nobody made a killer framework yet : it's a looooooot of work, it's hard, and it's very easy to get it wrong. Doing like <sync framework> but async doesn't cut it.
        sandGorgon 10y ago
    - sametmax 10y ago
      I'd like to chat with you about this, share ideas for API, and architectures. Even if we don't work to each others, we can benefit from sharing ideas about what should a next gen framework look like in Python.
  - shuzchen 10y ago
    There is already http://www.tornadoweb.org/en/stable/ http://www.tornadoweb.org/en/stable/ which is python3 compatible and shipped in production software across lots of companies (last I heard hipmunk and quora uses it)
    - sandGorgon 10y ago
      Tornado is excellent... But Flask is better than excellent. The mental map of Flask is incredible. Tornado is a little hard to grok. Now one may argue that Tornado is hard by choice...to not mask the complexity. But then we have node..the most hip of frameworks out there. Node's true innovation was not performance, but to simplify the mental model of async. Obviously there's all the callback hell and all..but still.
      - mayhew 10y ago
        I'm pretty sure both Node and Tornado have the same mental model of async. Both have callbacks and both have async/await functionality that makes it look more like blocking code. The main benefit of Node as I see it is that the entire Node community uses the same IO Loop whereas Python's community is fragmented between normal sync code and multiple different IO Loops (asyncio will probably help with this).
  - jsjohnst 10y ago
    Forgive me if I'm misunderstanding what you're looking for, but doesn't Tornado fit that bill?
    - sametmax 10y ago
      Tornado still too low level. - It's verbose compared to flask. - It reinvent the wheel, while flask uses great components such as werkzeug. - If you want to make a component, it's complex. - It doesn't come battery included for the Web like Django, just the bare minimum. - It misses the opportunity to provide task queues, RPC or PUB/SUB which are key components to any modern stacks are made easily possible by having persistent connections. - It ignores async/await potential of unifying threads/process/asyncio and don't allow easy multi-cpu. Don't get me wrong, I think tornado is a great piece of software, but it's not match against innovative projects we see in Go or NodeJS such as Meteor.
      - mayhew 10y ago
        Yeah, it's hard for Python to compete with languages like Go and Erlang that multiplex IO in the runtime.
        sametmax 10y ago
        It's not hard for the language, but we don't have the proper framework yet. Because such a framework is quite a task.
      - jsjohnst 10y ago
        We will have to agree to disagree on many of your points as they are mostly personal opinions, but the last one is flat wrong. Tornado has for a long time had great support for fully leveraging all CPU cores. Happy to show sample code if you like.
        sametmax 10y ago
        My mistake. My knowledge on tornado is dated.
  - dcosson 10y ago
    One problem with this is that the entire ecosystem has to get on board with async. Maybe a new framework would make it compelling enough, who knows. This was/is the big issue with Tornado, IMO (and Tornado has been around for ages in framework time). Tornado is only async if the entire call stack all the way down to the http socket is async, using callbacks instead of returning values. This means that any 3rd party client library you use has to be completely written asynchronously, and none are in python. So you end up with a lot tedious work re-implementing http client libraries for Twilio or Stripe or whatever you're using. I'm curious to see where asyncio goes in python, but I'm a bit skeptical after seeing how much of a pain it was to use Tornado on a large web app. In the meantime I'll be using Gevent + Flask, which isn't perfect since it adds some magic & complexity but has the huge upside of letting you keep using all the libraries you're used to.
  - gJigsaw 10y ago
    https://github.com/pyGrowler/Growler https://github.com/pyGrowler/Growler "A micro web-framework using asyncio coroutines and chained middleware."
- andrewgodwin 10y ago
  I'm the main person in Django working on 2), and this is interesting for sure, though our current code is based on Twisted since we need python 2 compatability (there's some asyncio code, but not a complete webserver yet)
  - rattray 10y ago
    What are the chances that Django Channels (the project I believe you're working on) will be able to ship with support for asyncio/uvloop?
qihqi 10y ago
The answer of 2) is likely to be "no" as wsgi is synchronous in nature. The only way to run it async is through gevent.
aidos 10y ago
You can use guv[0] if you're looking for a UV based version of gevent. I've used it before with good success. [0] https://github.com/veegee/guv/blob/develop/README.rst https://github.com/veegee/guv/blob/develop/README.rst

1st1 10y ago

1) I don't know :( I've answered a similar question in this thread with a couple of guesses. 2) No, they have a different architecture. Although I heard that there is a project to integrate asyncio into django to get websockets and http/2. 3) asyncio/uvloop require you to use explicit async/await. So, unfortunately, the existing networking code that isn't built for asyncio can't be reused. On the bright side, there are so many asyncio DB drivers and other modules now!

sandGorgon 10y ago
> 2) No, they have a different architecture Having a web framework (a next generation Flask if you will) built ground up with concurrency is the missing key. I have used Flask for many years, but this is the right time to introduce a new framework - because of the internal restructuring and slowdown of Flask's maintainers (and I say this with the utmost respect). If you are keen, this has the potential to be the killer application for Python 3.
- 1st1 10y ago
  I'm actually thinking about writing such a framework :) I'll call it "spin".
  - happytrails 10y ago
    sounds good! Go forth!
  - sandGorgon 10y ago
    You totally should. I think people are hungry for a next gen async web framework... And if it leverages Python 3, then so much the better. Flask cannot go here even if it wants because its core philosophy is to be WSGI compliant. You don't necessarily have to adhere to that. Just one point, please make sure you have designed DB access as a core part of your framework (e.g. [1]). Too many frameworks discount database interaction until it's too late. Oh and please please choose your name so that it doesn't conflict on Google search. http://www.spinframework.org http://www.spinframework.org [1] http://initd.org/psycopg/docs/advanced.html#async-support http://initd.org/psycopg/docs/advanced.html#async-support vs https://github.com/chtd/psycopg2cffi https://github.com/chtd/psycopg2cffi
    - jagger27 10y ago
      Since spin is conflicting, may I suggest spyn? Gets that nice little Python 'py' in there.
      - hasenj 10y ago
        Can also be read as "spine".
    - alexchamberlain 10y ago
      If such a framework was built around asyncio, do we really need yet another database layer? 1 of the best things about Flask is it doesn't reinvent the wheel.
      - sandGorgon 10y ago
        It's not so much as another dB layer, but some async compatible dB layer. Most database libraries don't play very well with non blocking code. In fact nodejs dB libraries were specifically designed for this. Building async frameworks is not trivial - http://initd.org/psycopg/docs/advanced.html#async-support http://initd.org/psycopg/docs/advanced.html#async-support
    - michaelmcmillan 10y ago
  - continuations 10y ago
    Go for it! An async python web framework with the speed of Go and the ecosystem of python would be a killer app.
    - sametmax 10y ago
      We are actually working on a project like this with Tygs (https://github.com/Tygs/tygs https://github.com/Tygs/tygs, which will use crossbar.io), and right now it's taking ages just to get the app life cycle right. Indeed, we want to make it very easy to use, especially a clean/discoverable API, simple debugging, clear errors, etc. Which is the stuff async frameworks are not good at, and an incredible added value. It's a lot more work we initially thought. When you are doing async, you now think, not with a sequence of actions ordered in time, but with events. So for your framework to be usable, you must provide hooks to: - do something at init - register a component - do something when a component is registered - do something once it's ready - do something when there is an error - do something when it shuts down With minimum boiler plate, and maximum clear error handling when the user try to do it at the wrong time or in the wrong way. But, we learned while coding the project that, with asyncio, exceptions in coroutine don't break the event look (except KeyboardInterrupt which is a weird hybrid) while exceptions from the loop do break it. Plus you have to make a nice setup, which auto starts the event loop with good default so that people don't have to think about it for simple apps. But it must be overridable, and handle the case where your framework is embeded inside an already started event loop, and make it easy to do so. It's one of the strong point of gevent: you don't have to think about it. With asycio/twisted, you have the benefit a explicit process switch and parallelism, but you need to pay the price with verbosity and complexity. We try to create a balance, and it's turns out to be harder than expected. Then you have to make clear error reporting, especially iron the implementation mixing Task, Futures, coroutine functions and coroutines. Provide helpers so that common scheduling is done easily... And you haven't even talked about HTTP yet. This is just proper asyncio management. This is why nobody made a killer framework yet : it's a looooooot of work, it's hard, and it's very easy to get it wrong. Doing like <sync framework> but async doesn't cut it.
      - sandGorgon 10y ago
  - sametmax 10y ago
    I'd like to chat with you about this, share ideas for API, and architectures. Even if we don't work to each others, we can benefit from sharing ideas about what should a next gen framework look like in Python.
- shuzchen 10y ago
  There is already http://www.tornadoweb.org/en/stable/ http://www.tornadoweb.org/en/stable/ which is python3 compatible and shipped in production software across lots of companies (last I heard hipmunk and quora uses it)
  - sandGorgon 10y ago
    Tornado is excellent... But Flask is better than excellent. The mental map of Flask is incredible. Tornado is a little hard to grok. Now one may argue that Tornado is hard by choice...to not mask the complexity. But then we have node..the most hip of frameworks out there. Node's true innovation was not performance, but to simplify the mental model of async. Obviously there's all the callback hell and all..but still.
    - mayhew 10y ago
      I'm pretty sure both Node and Tornado have the same mental model of async. Both have callbacks and both have async/await functionality that makes it look more like blocking code. The main benefit of Node as I see it is that the entire Node community uses the same IO Loop whereas Python's community is fragmented between normal sync code and multiple different IO Loops (asyncio will probably help with this).
- jsjohnst 10y ago
  Forgive me if I'm misunderstanding what you're looking for, but doesn't Tornado fit that bill?
  - sametmax 10y ago
    Tornado still too low level. - It's verbose compared to flask. - It reinvent the wheel, while flask uses great components such as werkzeug. - If you want to make a component, it's complex. - It doesn't come battery included for the Web like Django, just the bare minimum. - It misses the opportunity to provide task queues, RPC or PUB/SUB which are key components to any modern stacks are made easily possible by having persistent connections. - It ignores async/await potential of unifying threads/process/asyncio and don't allow easy multi-cpu. Don't get me wrong, I think tornado is a great piece of software, but it's not match against innovative projects we see in Go or NodeJS such as Meteor.
    - mayhew 10y ago
      Yeah, it's hard for Python to compete with languages like Go and Erlang that multiplex IO in the runtime.
      - sametmax 10y ago
        It's not hard for the language, but we don't have the proper framework yet. Because such a framework is quite a task.
    - jsjohnst 10y ago
      We will have to agree to disagree on many of your points as they are mostly personal opinions, but the last one is flat wrong. Tornado has for a long time had great support for fully leveraging all CPU cores. Happy to show sample code if you like.
      - sametmax 10y ago
        My mistake. My knowledge on tornado is dated.
- dcosson 10y ago
  One problem with this is that the entire ecosystem has to get on board with async. Maybe a new framework would make it compelling enough, who knows. This was/is the big issue with Tornado, IMO (and Tornado has been around for ages in framework time). Tornado is only async if the entire call stack all the way down to the http socket is async, using callbacks instead of returning values. This means that any 3rd party client library you use has to be completely written asynchronously, and none are in python. So you end up with a lot tedious work re-implementing http client libraries for Twilio or Stripe or whatever you're using. I'm curious to see where asyncio goes in python, but I'm a bit skeptical after seeing how much of a pain it was to use Tornado on a large web app. In the meantime I'll be using Gevent + Flask, which isn't perfect since it adds some magic & complexity but has the huge upside of letting you keep using all the libraries you're used to.
- gJigsaw 10y ago
  https://github.com/pyGrowler/Growler https://github.com/pyGrowler/Growler "A micro web-framework using asyncio coroutines and chained middleware."
andrewgodwin 10y ago
I'm the main person in Django working on 2), and this is interesting for sure, though our current code is based on Twisted since we need python 2 compatability (there's some asyncio code, but not a complete webserver yet)
- rattray 10y ago
  What are the chances that Django Channels (the project I believe you're working on) will be able to ship with support for asyncio/uvloop?

qihqi 10y ago

The answer of 2) is likely to be "no" as wsgi is synchronous in nature. The only way to run it async is through gevent.

aidos 10y ago

You can use guv[0] if you're looking for a UV based version of gevent. I've used it before with good success. [0] https://github.com/veegee/guv/blob/develop/README.rst https://github.com/veegee/guv/blob/develop/README.rst