4 ms·

For background, the author founded the Flask project [0] among others, and contributed to many other well-known Python projects. 0. http://lucumr.pocoo.org/pro

For background, the author founded the Flask project [0] among others, and contributed to many other well-known Python projects. 0. http://lucumr.pocoo.org/projects/ http://lucumr.pocoo.org/projects/

dom0 10y ago
Also https://www.palletsprojects.com/ https://www.palletsprojects.com/ Btw. does someone know why some things where moved from Pocoo to Pallets?
- loulouxiv 10y ago
  Armin wanted to step back a little from these projects and moved them to pallets in order to make them more community-driven
- __derek__ 10y ago
  Here's the blog-post announcing it.[1] [1]: https://www.palletsprojects.com/blog/hello/ https://www.palletsprojects.com/blog/hello/
ubernostrum 10y ago
For more background, Flask embodies a lot of what Armin likes about how to build things, and there's room to disagree with him on it. (for example, Flask attaches the request to a magic thread-local variable, while Django -- to pick the one I prefer -- requires you to explicitly pass it around and write functions to take it as an argument; there's a parallel in Armin's complaints about asyncio requiring you to explicitly pass things around instead of accessing magic thread-local storage)
- forgotpwtomain 10y ago
  From my understanding Armin's complaint isn't solely that you have to pass it around but the fragmentation of not having a standard way of doing it: >> pass the event loop to all coroutines. That appears to be what a part of the community is doing. Giving a coroutine knowledge about what loop is going to schedule it makes it possible for the coroutine to learn about its task. >> alternatively you require that the loop is bound to the thread. That also lets a coroutine learn about that. Ideally support both. Sadly the community is already torn of what to do. Personally I'm not clear on a lot of the minority-use cases that spawns some of this complexity (e.g. when and why would you need to move event loops across threads?) and am quite out of my depth as well.

For background, the author founded the Flask project [0] among others, and contributed to many other well-known Python projects. 0. http://lucumr.pocoo.org/projects/ http://lucumr.pocoo.org/projects/

dom0 10y ago

Also https://www.palletsprojects.com/ https://www.palletsprojects.com/ Btw. does someone know why some things where moved from Pocoo to Pallets?

loulouxiv 10y ago
Armin wanted to step back a little from these projects and moved them to pallets in order to make them more community-driven
__derek__ 10y ago
Here's the blog-post announcing it.[1] [1]: https://www.palletsprojects.com/blog/hello/ https://www.palletsprojects.com/blog/hello/

ubernostrum 10y ago

For more background, Flask embodies a lot of what Armin likes about how to build things, and there's room to disagree with him on it. (for example, Flask attaches the request to a magic thread-local variable, while Django -- to pick the one I prefer -- requires you to explicitly pass it around and write functions to take it as an argument; there's a parallel in Armin's complaints about asyncio requiring you to explicitly pass things around instead of accessing magic thread-local storage)

forgotpwtomain 10y ago
From my understanding Armin's complaint isn't solely that you have to pass it around but the fragmentation of not having a standard way of doing it: >> pass the event loop to all coroutines. That appears to be what a part of the community is doing. Giving a coroutine knowledge about what loop is going to schedule it makes it possible for the coroutine to learn about its task. >> alternatively you require that the loop is bound to the thread. That also lets a coroutine learn about that. Ideally support both. Sadly the community is already torn of what to do. Personally I'm not clear on a lot of the minority-use cases that spawns some of this complexity (e.g. when and why would you need to move event loops across threads?) and am quite out of my depth as well.