4 ms·

> Python code doesn't even work with Python code async / await are just primitives, they are, in no way, incompatible with the rest of Python code. At worst,

> Python code doesn't even work with Python code async / await are just primitives, they are, in no way, incompatible with the rest of Python code. At worst, if you mix blocking and non blocking, you loose the performance benefit, that's all. It all works. You are just back to non async execution. You can use async functions in sync code and vice-versa. In fact, you can use async / await for asyncio, or another lib, or no lib at all, it's a completly lib agnostic concept. It doesn't even need any io. async / await is just a "yield from" which understands __await__. It's an interface. A contract. Like generators. What's more, the python community is now following the best pratice of creating Sans I/O libs (https://sans-io.readthedocs.io/ https://sans-io.readthedocs.io/), which means you can plug in whatever I/O lib you want. There is a lot of confusion around asyncio, partly because of the communication and doc around it, partly because it sucked up until python 3.7, and partly because a lot of python devs have absolutely no need for it and see it from the point of view of their day to day task. But it's definitly not fiasco, it's quite a handy tool, and the generic interface of async / await is nifty and allows cool designs.

jakogut 6y ago
Can you summarize how Python async improved in 3.7?
- BiteCode_dev 6y ago
  Not async in general, but asyncio in particular. Before 3.7, you had to be able to fetch the loop, handle its reference, pass it around, manage its life cycle, etc. Starting from 3.7, only low level code (E.G: framework authors) would need to, the API is organized so that by default, you always perform something in the current running loop. It's a big deal, and remove a ton of complexity. Maintenance is easier, learning curve is flatter. The best example, is that in 3.6 and lower, you had to do "loop = asyncio.get_event_loop()", then call "loop.run_until_complete()". In 3.7, you use asyncio.run(). It seems trivial, it's really not: https://github.com/python/asyncio/blob/db2fe1d1e1d0f7352167a2ff00c4296115810adc/asyncio/run.py#L11 https://github.com/python/asyncio/blob/db2fe1d1e1d0f7352167a.... This has consequences on the whole design, which is now full of things like that (run_in_executor, create_task, run_forever, etc), changing completly the way to write correct code. Another thing is that in 3.7, the asyncio uses async / await and not yield from. Because of this dog fooding, the whole lib improved. 3.7 has a LOT of patches just for asyncio: https://docs.python.org/3.7/whatsnew/changelog.html#python-3-7-0-final https://docs.python.org/3.7/whatsnew/changelog.html#python-3... Speed (Future has been rewritten in C, and many other tweaks), fixes, _way_ better doc... Obvious shortcomming were resolved, like asyncio.wait_for() that now waits until the cancellation is complete, or asyncio.all_tasks() returning only pending tasks. A lot of little things that add up. The whole ergonomics are better, up to the command line experience with "python -X dev" which automatically add warnings and set asyncio in debug mode, and frankly you can't cleanly code async without. The final nail in the coffin are the context vars (https://docs.python.org/3/library/contextvars.html https://docs.python.org/3/library/contextvars.html). It's the only sane way to deal with a global registery that is dependant of the current running task. It's almost always easier to upgrade to 3.7 than trying to use asyncio before it.
skrtskrt 6y ago
Asyncio rocks. It’s so easy to create performant little apps that can get put up without a web server in front of them. Type hinting rocks. Use it properly everywhere and you can a lot of confidence and speed when refactoring. I use attrs (I know there are alternatives) to get legit type checking on object fields. Yes it is runtime type checking but if you write tests, those errors will pop up before you ever run the app. Honestly I think the priority with Python should just be around digging deep into the implementations for performance gains. I’m very happy with how the ergonomics of the language are now.

jakogut 6y ago

Can you summarize how Python async improved in 3.7?

BiteCode_dev 6y ago
Not async in general, but asyncio in particular. Before 3.7, you had to be able to fetch the loop, handle its reference, pass it around, manage its life cycle, etc. Starting from 3.7, only low level code (E.G: framework authors) would need to, the API is organized so that by default, you always perform something in the current running loop. It's a big deal, and remove a ton of complexity. Maintenance is easier, learning curve is flatter. The best example, is that in 3.6 and lower, you had to do "loop = asyncio.get_event_loop()", then call "loop.run_until_complete()". In 3.7, you use asyncio.run(). It seems trivial, it's really not: https://github.com/python/asyncio/blob/db2fe1d1e1d0f7352167a2ff00c4296115810adc/asyncio/run.py#L11 https://github.com/python/asyncio/blob/db2fe1d1e1d0f7352167a.... This has consequences on the whole design, which is now full of things like that (run_in_executor, create_task, run_forever, etc), changing completly the way to write correct code. Another thing is that in 3.7, the asyncio uses async / await and not yield from. Because of this dog fooding, the whole lib improved. 3.7 has a LOT of patches just for asyncio: https://docs.python.org/3.7/whatsnew/changelog.html#python-3-7-0-final https://docs.python.org/3.7/whatsnew/changelog.html#python-3... Speed (Future has been rewritten in C, and many other tweaks), fixes, _way_ better doc... Obvious shortcomming were resolved, like asyncio.wait_for() that now waits until the cancellation is complete, or asyncio.all_tasks() returning only pending tasks. A lot of little things that add up. The whole ergonomics are better, up to the command line experience with "python -X dev" which automatically add warnings and set asyncio in debug mode, and frankly you can't cleanly code async without. The final nail in the coffin are the context vars (https://docs.python.org/3/library/contextvars.html https://docs.python.org/3/library/contextvars.html). It's the only sane way to deal with a global registery that is dependant of the current running task. It's almost always easier to upgrade to 3.7 than trying to use asyncio before it.

skrtskrt 6y ago

Asyncio rocks. It’s so easy to create performant little apps that can get put up without a web server in front of them. Type hinting rocks. Use it properly everywhere and you can a lot of confidence and speed when refactoring. I use attrs (I know there are alternatives) to get legit type checking on object fields. Yes it is runtime type checking but if you write tests, those errors will pop up before you ever run the app. Honestly I think the priority with Python should just be around digging deep into the implementations for performance gains. I’m very happy with how the ergonomics of the language are now.