5 ms·

The conclusion to stick to Python 2 just because the author does not like some optional features added in Python 3 seems far fetched. While the typing thing ha

The conclusion to stick to Python 2 just because the author does not like some optional features added in Python 3 seems far fetched. While the typing thing has been discussed here yesterday[0], I share his views about asyncio. I was a bit disappointed when asyncio lost its provisional status in Python 3.6. I was hopping that the community will wait a bit more and settle on something else. The work that David Beazley does on Curio[1] is amazing. This should be an inspiration for the standard library in my opinion. [0] https://news.ycombinator.com/item?id=13730494 https://news.ycombinator.com/item?id=13730494 [1] https://github.com/dabeaz/curio https://github.com/dabeaz/curio

jimnotgym 10y ago
I guess thats the point though, you don't have to use asyncio, in the same way most use requests rather than urllib.
spangry 10y ago
Agreed on Curio. Although async will probably never be straightforward (at least not in the way sequential execution is), grasping Curio is a walk in the park compared to learning the mystical magic of Asyncio. I would also just add, more generally, that while the standard library documentation is extensive, if there is any organisation principle behind it I have yet to discover it.
scriptkiddy 10y ago
Python has a history of treating standard library modules as a sort of reference implementation. Look at urllib and urllib2 for example. No self respecting Python dev will use either of those two packages if they can help it. They'll use requests instead. Other examples include Python's standard library json/xml parsers. Nobody really uses them out of the box. In my work, the only standard library module I really use extensively is the collections module.
- nicolaslem 10y ago
  It's funny I have the exact opposite approach to the standard library. Sure some modules like urllib are really bad and I avoid them, but for the rest when the standard library gives me something I use it. I often find myself going through the standard library documentation and it's a real pleasure to read and discover things that I didn't know were just an import away. I use the standard json module all the time and I never felt like it was holding me back. I don't write performance critical software so I tend to value the simplicity more than the performance gain.
  - scriptkiddy 10y ago
    In the case of the Json module, I totally agree. I'm not really concerned with Performance either. It's mostly API flexibility that I care about. I mean, urllib is always such a great example of an overcomplicated and inflexible API with bad naming conventions. The Json module really did a good job in learning from previous mistakes. `json.loads()` and `json.dumps()` couldn't be any easier to use. Though, I would argue that the json module's ease of use is owed more to the fact that Python dictionaries map pretty much 1-to-1 with JSON already.

jimnotgym 10y ago

I guess thats the point though, you don't have to use asyncio, in the same way most use requests rather than urllib.

spangry 10y ago

Agreed on Curio. Although async will probably never be straightforward (at least not in the way sequential execution is), grasping Curio is a walk in the park compared to learning the mystical magic of Asyncio. I would also just add, more generally, that while the standard library documentation is extensive, if there is any organisation principle behind it I have yet to discover it.

scriptkiddy 10y ago

Python has a history of treating standard library modules as a sort of reference implementation. Look at urllib and urllib2 for example. No self respecting Python dev will use either of those two packages if they can help it. They'll use requests instead. Other examples include Python's standard library json/xml parsers. Nobody really uses them out of the box. In my work, the only standard library module I really use extensively is the collections module.

nicolaslem 10y ago
It's funny I have the exact opposite approach to the standard library. Sure some modules like urllib are really bad and I avoid them, but for the rest when the standard library gives me something I use it. I often find myself going through the standard library documentation and it's a real pleasure to read and discover things that I didn't know were just an import away. I use the standard json module all the time and I never felt like it was holding me back. I don't write performance critical software so I tend to value the simplicity more than the performance gain.
- scriptkiddy 10y ago
  In the case of the Json module, I totally agree. I'm not really concerned with Performance either. It's mostly API flexibility that I care about. I mean, urllib is always such a great example of an overcomplicated and inflexible API with bad naming conventions. The Json module really did a good job in learning from previous mistakes. `json.loads()` and `json.dumps()` couldn't be any easier to use. Though, I would argue that the json module's ease of use is owed more to the fact that Python dictionaries map pretty much 1-to-1 with JSON already.