Live data from Hacker News

New features you can't use unless you are in Python 3

asmeurer.com

81–90 of 264 posts

Re: New features you can't use unless you are in Python 3

#81

Asyncio is the most important feature of 3.5+ imo. I'm not sure why this is buried at #8.

The new async features are kind of a mess. Many Python users just don't have the use case to make it worth digging in to it.

But the ones that do absolutely love it. At least, I do.

Re: New features you can't use unless you are in Python 3

#82
post #9
post #4

I'm impressed how much Python seems stuck on older versions. What went wrong?

It wasn't broke and they fixed it. Python 2 is a mature language with a robust ecosystem. Those just don't go away no matter how much developers nag people to upgrade.

Except it was, and badly. Unicode support reached sanity matching Java or C#, if only just, but for me the most important fix was making exceptions actually work instead of being a broken pile of workarounds glued together with ambiguous and/or confusing syntax.

Re: New features you can't use unless you are in Python 3

#83
post #10

Earlier quoted context omitted.

Because after nearly 10 years this mediocre list is the best they can offer as consolidation for breaking your code, and for much of that time they didn't have everything it does now. If py3k shipped with something like https://gregoryszorc.com/blog/2017/03/13/from-__past__-impor... there probably would have been more uptake.

This piece barely scratches the surface, there's formatted string literals, type checking available, and compact ordered dicts by default in the latest. All awesomeness. I'm glad they did the "mediocre" fixes as well, they lead to a lot fewer encoding (and other) bugs, which were a real problem on nontrivial programs.

Type checking is given in the piece. Compact dicts are nice for memory performance, but I don't use Python for performance. Ordered dicts I only care about rarely and explicitly use one in such cases. Formatted string literals have not really been a "feature" but a concern. The original plan was to get rid of the % way of formatting and just use .format with __format__ (except now there are pitfalls and inconsistencies with different types of strings). Now Python 3.6 has string interpolation with f-strings, which is kind of nice, but I've never really missed it when I come back from using other languages with it, and if I really wanted it there has been tools like Interpy. That last bit is kind of the nail in the coffin, a lot of Py3 features have been available as Py2 libraries or higher source parsing tools longer than the feature has been in Py3.

I didn't like how the changes to strings and bytes were made, but that's probably a larger discussion, and fits within how Py3 has evolved. If anyone is really confused by the struggle with adoption, just look through the release notes of version by version, and ask at what point there's a compelling reason to upgrade. I still don't see one, but at this point, nearly 10 years after Py3k, Py3.6 is finally usable enough that I wouldn't mind as much if I had to work on a Py3.6 codebase instead of a Py2.7 one.

Re: New features you can't use unless you are in Python 3

#84
post #10

Earlier quoted context omitted.

Because after nearly 10 years this mediocre list is the best they can offer as consolidation for breaking your code, and for much of that time they didn't have everything it does now. If py3k shipped with something like https://gregoryszorc.com/blog/2017/03/13/from-__past__-impor... there probably would have been more uptake.

This piece barely scratches the surface, there's formatted string literals, type checking available, and compact ordered dicts by default in the latest. All awesomeness. I'm glad they did the "mediocre" fixes as well, they lead to a lot fewer encoding (and other) bugs, which were a real problem on nontrivial programs.

[deleted]

Re: New features you can't use unless you are in Python 3

#85
post #20

Does anyone use 2.x by choice? I've only seen it required as to not break legacy code.

Yes. My reason is that I simply don't really care that much. It's the default on all my systems, so why bother putting in the effort to use something that doesn't appear to offer much advantage to me personally? I use python for my personal research, so my particularly situation affords me this laziness. edit: I don't mean this as a knock on py3. All I'm saying is that my situation and uses for python allow me to be…

I'm in similar situation wrt what I use python for, and suffered from the same apathy until quite recently. Man, it was really easy to switch, and completely worth it just for the little things (like UTF-8 as default encoding for strings). It's really painless, but if you want to ease into it, I recommend using __future__ in your py2 stuff for now just to get you into a py3 state of mind: https://docs.python.org/2/library/__future__.html

Re: New features you can't use unless you are in Python 3

#88

TL;DR: The important stuff that makes a good case for Python 3: - Adittion of "yield from" allows easier programming with async I/O "a la " Node.js (using 'await') - Standarized annotations of function arguments and return values can help in the future for type checking, optimization, etc. Even more important stuff - Unicode can be used in symbols. You can now use Kanji characters in your function names, to annoy you…

Of those, only the async I/O stuff seems compelling. But compelling it is, at least as used in Curio. It feels like this is still shaking out, with the standard library and Trio (?) alternatives, but it looks really cool.

Re: New features you can't use unless you are in Python 3

#90
post #76
post #20

Does anyone use 2.x by choice? I've only seen it required as to not break legacy code.

Most people who use a language are actually working on code that existed before yesterday. I work on a codebase that was written in python 2, and when we looked at the cost of upgrading it to python 3 versus adding new features, it was a no brainer. I have no desire to switch to python 3, nor do I anticipate ever doing so, at least for the projects I'm working on now. If you are maintaining a large or important codeb…

> if we are forced to stop using python 2, we'll probably need to switch the project over to Java.

This is just silly. It will take at least 100x more effort to rewrite the project in Java than it would to upgrade to Python 3.

> at least the java community doesn't force developers to rewrite their source code when a new JVM comes out

Yes, that was an unfortunate, one-time thing for Python that happened almost a decade ago.

> My employer is mostly a java shop ... and their retort is that [python is] not really enterprise ready

Yep. That sounds like the kind of nonsense people say in a Java shop.

Post reply on HN