3 ms·

I'm actually thinking about writing such a framework :) I'll call it "spin".

by 1st1 10y ago

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
  > 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. I strongly advise against this. One of the reasons Flask is so attractive is the fact that it does not enforce any database on you. Thanks to its decoupled design you can use it purely as a routing library, which is great! Letting the framework decide something important as the database is a bad idea. [1] [1] https://blog.8thlight.com/uncle-bob/2012/08/13/the-clean-architecture.html https://blog.8thlight.com/uncle-bob/2012/08/13/the-clean-arc...
  - sandGorgon 10y ago
    that is ok - but there is a representative library that works. Loosely decoupled but definitively working is beautiful... and this is why I use Flask in my startup. what frequently happens is a web framework without a thought for any kind of DB interaction (or as you put it... a routing library). In things like an async web framework, that could leave users hanging. For example, psycopg vs psycopg2 vs psycogreen vs psycopg2-cffi . Tell me which one to use and benchmark it. I agree, its a fine line. And we can keep going back and forth whether a framework should "recommend" or not recommend. But in case like this - I think there will NOT be a lot of libraries that will be compliant with the async usecase. I would hope that this framework will recommend... but not ship "batteries included".
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.

I'm actually thinking about writing such a framework :) I'll call it "spin".

by 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
> 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. I strongly advise against this. One of the reasons Flask is so attractive is the fact that it does not enforce any database on you. Thanks to its decoupled design you can use it purely as a routing library, which is great! Letting the framework decide something important as the database is a bad idea. [1] [1] https://blog.8thlight.com/uncle-bob/2012/08/13/the-clean-architecture.html https://blog.8thlight.com/uncle-bob/2012/08/13/the-clean-arc...
- sandGorgon 10y ago
  that is ok - but there is a representative library that works. Loosely decoupled but definitively working is beautiful... and this is why I use Flask in my startup. what frequently happens is a web framework without a thought for any kind of DB interaction (or as you put it... a routing library). In things like an async web framework, that could leave users hanging. For example, psycopg vs psycopg2 vs psycogreen vs psycopg2-cffi . Tell me which one to use and benchmark it. I agree, its a fine line. And we can keep going back and forth whether a framework should "recommend" or not recommend. But in case like this - I think there will NOT be a lot of libraries that will be compliant with the async usecase. I would hope that this framework will recommend... but not ship "batteries included".

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.