Good. The glacial migration from Python 2 to 3 is one of the worst things about an otherwise fantastic ecosystem. The tide is turning though, with Django having already dropped support for 2, and now with Numpy too hopefully Python 2 can be properly consigned to the history books.
For people wondering why it's been like this for almost a decade(!) since Python 3.0 was released: Python 3.0 was actually terrible. It lacked many critical things, and was riddled with bugs and security flaws until 3.3, which was released 4 years after 3.0. This cemented in many people's minds the idea that Python 3 was a bad thing. Python 2 was and is a fantastic programming language, so it was a very high bar to move up from. Python 3 has come a long way since then, Python 3.6 is now a decent step up from 2.7.
Frankly, I still haven't seen a single reason to switch to Python3 beyond the fact that the original authors have gotten bored of providing security and bugfix updates and will stop in 2020. That's it.
The only thing in the last decade or so of Python3's existence that even got me slightly interested in using it was asyncio, and after looking into it a bit, it frankly seems like more trouble than its worth.
I know Python 2.7 extremely well. It works perfectly fine for just about everything I use it for. It's STABLE. For the tasks I use it for, it runs faster than Python3... (Not that performance is my greatest concern when using Python.) So, please tell me -- why on earth is it a good thing that people are trying to kill off Python2? What exactly makes Python 3.6 a "decent step up" from 2.7? I'm still at the point of thinking, as you said, that Python3 is a bad thing.
why on earth is it a good thing that people are trying to kill off Python2?
Because the community is fragmented and that weakens language adoption, productivity, and enjoyment.
The 2-3 schism in Python has been a pain to deal with for years. I use Python casually here and there, but I'm so sick of trying to do something quickly in Python and finding out that I'm on a machine that only has 2 but the module I need is only for 3 or having the bulk of my app written in 3 but the only version of a module I need is for 2.
Same goes for examples you find on the Internet to do a particular thing. Ooops, it's 2.x syntax/modules so you have to fix it up for 3. Ooops, it's 3 syntax/modules so you have to fix it up for 2.
For the good of any computer language, old versions need to eventually die off.
> Frankly, I still haven't seen a single reason to switch to Python3 beyond the fact that the original authors have gotten bored of providing security and bugfix updates and will stop in 2020. That's it.
It seems pretty clear now that 3rd party library developers are going to stop releasing packages that support 2.x and target only 3.x. Isn't that a bigger problem for Python 2.7 hold outs?
Originally, I was not super excited about Python 3. I liked "print" as a keyword. I liked the space efficiency and speed of latin-1 strings by default. I did a lot of network protocol stuff and bytes() was a pain to use. I knew how to use the 'u' prefix to get unicode when I needed. However, after using Python 3 for a few years now, I find Python 2 clumsy. Print as a function is better. Unicode works better. The implementation is just as fast or faster than Python 2 and getting faster every release. If you tried Python 3 a few releases ago, you should give it another go. It has matured a lot.
This is an ancient argument because no one can convince you that you need 3 for your use case. All I can do is say why I like it, and list reasons that probably don't apply to you or you would have switched already.
For example, print and division made more sense to me in 3, judging from friends who taught 2 and said those were always sticky for some students in every class. Intuitive lowers the barrier to entry. (But 2 is probably more intuitive to you because it's second nature to you by now.)
Unicode--when I would test some tiny scripts with Chinese characters or weird ciphers--was pretty easy out of the box in 3.
On systems that only support 2 I find myself slipping in basically a 'from future import all the things.'
These are admittedly mostly cosmetics. But cosmetics matter for noobs like I was, or maybe still am.
I guess 3 also fixed ambiguity in corner cases for error handling? Never came up for me so I don't know much about that one.
You probably just don't have those use cases?
Two people could use distinct subsets of python and neither is using it wrong. Meaning... there could be reasons many of us want 3 that simply don't apply to you. Which sucks, because you get hit with switching costs to help the rest of us.
I think that's the recipe for an endless debate with two reasonable sides.
I will say py2 was already fragmented without 3. PaiMei only ran on... 2.4 maybe? You'd find weird projects that you liked that would then get abandoned. Suddenly you're shimming them all or running four versions. I think 3 woke people up to this as a problem--by making it much harder to patch and way more universal. That made the project more conscious about future and backwards compatibility. Those dividends will only be seen over time. I hope they vest but can't prove how or if they have.
I hope this is helpful... Just know that I'm not saying you're wrong to want to use something that works for you. Switching costs are a real thing, I know it sucks to feel dragged along. But py3 is a lot better for me and others, possibly because we're using the language for different things.
The change to string handling justifies it for me. Writing `u’foo’` everywhere is a pain, and the rest of the 2.7 model is extraordinarily prone to runtime errors. With 3.6, I don’t have those problems.
Sure, you can continue using Python 2, and it's going to work for you. I guess you can also keep using Windows XP (no reason not to use it beyond the fact that Microsoft has gotten bored of providing security and bugfixes), and code using your PS/2 keyboard...
Generally speaking, Python 3 is actually faster now. I am a bit surprised that no one else has commented on this. There was a talk about performance recently (https://www.youtube.com/watch?v=d65dCD3VH9Q). To sum it up, some parts are slower and other parts are faster, and the reasons depend on two questions:
1: Is it using a lot of small ints? Python 3 changed int from being small int to long int, and for work which deals with massive amount of ints this will result in a slow down. If for some reason you want to use a pure Python implementation of AES rather than using hardware acceleration (generally builtin to the CPU) or a C implementation, or the one built in the linux kernel, then you will hit the performance test that get the biggest negative difference between python 2.7 and master. Then there is numpy which uses C modules that can happy do things as small ints.
2: Bytes -> Unicode. Libraries that are Unicode unaware will run faster than libraries that are Unicode aware. The feature to understand that "ö" is a Swedish letter and not several characters does cost some CPU time. For parsing where per character manipulation is relevant (like say HTML), such parsing will be a bit slower in python 3.
Practically everything else is faster now in python 3.
> What exactly makes Python 3.6 a "decent step up" from 2.7?
The language and the standard lib improved a lot. There are so many improvements, it would be impossible to list them all after so many years of progress...
Just to name a few of the bigger improvements, that I have discovered recently:
* The typing module lets you add type annotations to your code and write code like this:
class User(NamedTuple):
id: int
name: str
age: int
def remove_user(u: User) -> None:
# ...
fred = User(123, 'fred', 42)
# ...
remove_user(fred)
Frankly, I still haven't seen a single reason to switch to Python3
This typically means one of two things:
1. You've never really looked at the features added in the Python 3.x release series, or
2. You develop abandonware which plans never to upgrade any part of its platform ever, for any reason, and so no conceivable new feature would be sufficient to convince you to do an upgrade.
At this point (1) is untenable because of how many people have written about the useful things available in 3.x, and (2) is disingenuous (but there are still plenty of people who use "don't see a reason to upgrade" as an excuse for "I always planned to abandon this").
Just in case you're one of the people in (1), here you go:
For anything non-trivial, 95% of the value is in the library ecosystem. So long as most prominent libraries kept releasing new features for Python 2 and 3, there's inevitably not a big pull factor to upgrade. That's changing as a number of major libraries start to make releases that require Python 3.
From a library maintainer POV, I do want to use Python 3. There's no one killer feature, but rather a bunch of small ones, like more specific exception classes (FileNotFoundError etc.).
But if you want to keep using Python 2.7, no-one will take it away from you.
Nobody is forcing you to stop using Python 2.7, but the rest of the world is getting over it and moving on.
I'm sorry if that seems mean, but in the grand scheme of things the differences between 2 and 3 are pretty trivial, and most people still complaining about this are just being stubborn. I refuse to believe somebody can know Python 2.7 "extremely well" but then also need more than ten years to learn the few areas where Python 3 is different.
The killer feature of Python3 is string representation. IO work in python2 (e.g. network programming) was made more complicated by the evolutionary mess of python2's string design.
If you want to get strong at network programming without spinning up on all the complex topics in async io (coroutines, futures, etc), you may like my networking system: github.com/solent/solent-eng
It is designed to allow the programmer to reason about exactly what the process is doing, rather than to hide things away.
The docs are not in great shape at the moment. Good starting points: the telnet client (in tools) and the snake game (demo package).
This was originally in python2. I moved because of subtle improvements in python3 packages over python2. But once I appreciated the string changes, I wished I had moved much earlier.
It's a presentation by core developer Brett Cannon which explains what's better about Python 3. The list is quite long for an HN comment, so I'm not going to repeat it here.
Now it's pretty dated as there had been more things added like async, so Python 3 is even better now.
There's all the pain of python 2's string/byte handling... is it a byte str? Or unicode code points? Python 2 likes to keep you guessing, and that's not a good thing. If you haven't felt the pain here, there's a good chance your stuff is subtly broken in ways you may not be aware of.
Moreover there were some packages even last year that were simply broken with Python 3.x. What am I supposed to do if I have to deliver something to a client and the Python 3 version of my stack is broken? I do not necessarily have the time to debug the issue and fix it and it is much easier to switch to 2.7 and just continue working on the business problem. Software guys (especially guys working on programming languages and environments, tools) have to understand that providing a broken alternative is not an real option at all.
Anyways, I haven't been running into issues with Python 3 recently and I use it as much as I can.
Python 2.7 has just about the worst unicode handling of ANY language I've ever used.
Plenty of otherwise crappy languages (Java, JavaScript, etc) managed to make one right choice when they decided that strings are always unicode and bytes are a different data type entirely.
Also, the asyncio implementation in Python 3, while a bit complicated, is on the whole very nice, providing a lot of flexibility.
Long story short, if you still think Python 3.6 is "bad" in this day and age then you need to move on to another language.
It's a bunch of smaller things, but I think the major one is the new compact dict implementation. Using less memory is a good thing and you basically get it for free using Python3.
Python2's unicode support is kind of an error-prone mess and that was what prompted the decision to make 3 a breaking change in the first place. It is much harder to shoot yourself in the foot with text handling in 3 IMO, though it's certainly still not perfect. Of course lots of people think their programs with broken unicode handling work fine until someone passes them data in any language other than English.
If you ever need to deal with encoding, you will very soon know why my friend. I've hated Python3 just as much but reality left me with no choice. It's time to say goodbye sooner rather than later.
Wild speculation (I'm relatively new to Python), it might also have to do with the Python community having several personalities.
Python 3 solves a lot of problems for me, as someone who does a lot of NLP work, and generally has to deal with strings from the outside world and multiple languages and all that on a more-or-less constant basis. I imagine it solves some problems for Web developers, too, though possibly to a lesser extent. But I don't see a whole lot of devops people being eager to jump off of Python 2, and I'm not sure I see it solving more annoyances in that domain than the process of migrating to Python 3 would create, either.
Agreed. My background is also in NLP and I made the switch to Python 3 early and enthusiastically because it resolved a lot of issues around working with multilingual text.
I think there were also more compatibility issues prior to 3.3 (when they started allowing u"") for libraries that did want to support both. It seems like the core team predicted that the most popular migration path for libraries would be `2to3` or something like that, when in fact the single-codebase-supporting-both strategy has been much more popular? Probably the transition would've been easier if everyone had seen that coming.
That's correct. If something like "six" would have been provided as part of 3.0, things would have went more smoothly. There could have been some language changes in 3.0 to make single-codebase easier. It was only later that the core developers realised that would be the normal way for libraries to support Python 3 (e.g allowing u prefix on strings in 3.x). Quite a bit of time was wasted while this got sorted out. Things are a lot better now. Soon, I think most people will stop worrying about 2.x backwards compatibility.
Yeah, for the longest time everyone kept using library support as an excuse for sticking with 2. But at this point I think it's the exception that a decent Python library doesn't support 3, rather than the rule.
The only one that comes to mind for me is fabric, to be honest.
I have always been interested in that cycle. We use 2 because NumPy supports it still. NumPy supports it because we use it. If a major library had dropped support earlier on, I am curious what would have happened.
> The only one that comes to mind for me is fabric
Speaking of Fabric, does anyone know of any Python 3 projects similar to it? I've been using Fabric3 since the switch but it's not a 1:1 port. I'd consider dropping it in favor of something better if it exists.
It's not just libraries that I use when developing.
Searching for code snippets and copy/pasting stackoverflow answers can easily take more time out of my days than library documentation. But it's so much slower when I have to rewrite something I found for python 3.
Yes, but during the long migration, it was no mere excuse.
Almost every time I tried to use a library, it was 2.7 only.
That situation has only changed recently, and with it people have moved on to 3. (Which sort of underscores that the library support was the main issue).
Not having a story for interoperability between 3 and 2 was incredibly shortsighted. The migration path from Objective-C to Swift is an example of how to do this sort of transition right; Python got it wrong.
Widespread adoption of Python 3 would've happened years earlier if you could start a new project in Python 3 and not have to worry about libraries you want to use not supporting it yet.
The Swift 1->2->3 breakage has permanently poisoned the ever-important well of StackOverflow answers.
For some tasks, there are literally 5 mutually incompatible syntaxes to understand (Obj C, Swift 1234). Even though the UI can sometimes autoconvert for you, it doesn't help at at when you're looking at someone else's code.
Django has not dropped Python2 yet. Django 2.0 will drop Python2 but that has not yet been released, and Django 1.11 (with Python2) support will be supported in LTS for several years.
In stark contrast to the brutal python 2-3 dichotomy, I feel compelled to express my gratitude for the degree to which — contra all the hating and churn and “fatigue” — es6+ (transpiled to es5 via babel) has become such a pragmatic and obvious center of gravity.
Yeah, why isn’t that part of the python ecosystem? Is the reason that unlike the browser, it is possible to upgrade the major version, so there wasn’t that driving force to support an ecosystem for transpiring?
There are gargantuan Python2 projects out in the wild which are expected to continue, and can't realistically be migrated to Python3. In 15 or 20 years we'll be looking at those jobs the same way we look at Perl jobs today.
If this is the case then wouldn't re-naming it Python 4 shake the negative view of it? Guess it's too late now for Python but I've seen it done in other open source projects and it worked pretty well.
I wonder whether Python itself will improve faster when the development team no longer needs to maintain 2 versions or whether the burden on them will just reduce somewhat.
We use Appengine, which only supports python 2.7. As well as being a reason for us to stick with 2.7, I imagine Google prefers what is effectively a LTS release. If (hopefully "when") they provide 3.x, they will need significantly more support resources to keep up with continual releases.
The following example is pretty much the chief reason why I will not be porting much software to Python 3:
$ python3
Python 3.6.3 (default, Oct 3 2017, 21:45:48)
[GCC 7.2.0] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> 4/3
1.3333333333333333
Python3 is basically a different language than Python 2. If I wanted to port software to a different language, I would use any number of available languages that make other kinds of improvements over Python as well. The only remaining use case for Python for me will be as a quick scripting language, and data analysis and graphing tool.
It is a change, but you can use the // operator for floor division:
$ python3
Python 3.6.3 (default, Oct 3 2017, 21:16:13)
[GCC 7.2.0] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> 4//3
1
When I use python as a scripting language for small tasks I want something concise and convenient that just works. Python 3 is a downgrade in all those areas. I want to just some input into a string, do some operations on it, and print the result. Now I have to make extra special sure to convert the string between binary or utf8 as appropriate, catch encoding exceptions, not try to print anything that might have binary in it, and even the simple print statement was caught in this impractical mess that feels like it was designed by an out of touch academic committee comprised of people who'd never written real code in their lives deciding that string should actually mean only printable characters within a defined encoding and that statements are considered harmful. I can't wait for return to be a function too in python 4.
I suggest reading the eev.ee article others are linking in these comments. Or Joel Spolsky's "Back to Basics" article. Both do a pretty good job of highlighting some of the complexity in this area, and why things sometimes seem like they're being made harder.
Put most concisely, it's something like "making the most common use case as easy as possible can make slightly less common use cases wrong, dangerous and hard".
It's not an out of touch academic committee making these changes out of ignorance or spite. It's people who have to support more use cases than yours. Even if yours is the most common, that doesn't mean that the rest (internationalization, binary data transfer) are distant, rare outliers, or that the frequency of non-traditionally-"simple" ascii text handling applications isn't changing.
You don't need to do any of that. If you use `input()`, you get a string - all conversions are done for you. If you're reading from a file (or from stdin, treating it as a file object), again, in text mode you just get strings. Same thing for printing - if you print strings, they will get converted to the encoding appropriate for the target terminal.
> When I use python as a scripting language for small tasks I want something concise and convenient that just works. Python 3 is a downgrade in all those areas.
Funny, I found the exact opposite, and despite $dayjob being LCD(2, 3) and the default Python on my system being 2, I've been writing all my small scripts in 3.6.
As a library writer, I cannot wait until we get rid of this self-inflicted handicap of writing in a subset of two incompatible languages. I'm glad the heavyweights are joining the cause.
This is great news. I've been working with Python 3 for a few years now, and it really is a nicer language than 2. Granted 2.7 is a hard act to follow.
Even though the transition from 2 to 3 has been slow, I take it as a positive sign about the Python ecosystem. The general Python community has traditionally erred toward stability, and conservative feature introduction. The gradual introduction of large changes to the core language reflects that characteristic.
Hopefully this will cajole Python 2.7 users to migrate. Assuming you have decent test coverage, the migration generally isn't that difficult.
If you do a lot of NLP or string processing, the sane unicode support is worth it alone.
It's not strange. Python developers might declare Python 2.X EOLed, but that won't stop people from using it. Like it or not, Python 2.X is not going away.
There are big companies with huge legacy 2.x codebases who will stall as long as possible. But popular libraries are dropping 2, and many new libraries aren’t supporting it to begin with. Python 2 is accelerating toward irrelevance.
How do you plan on getting on when packages from PyPi stop supporting Python 2 at all? When Django, flask, numpy, requests, pandas, and more just don't even install? Will you just use ancient versions?
Also, Python is the only ecosystem I know of where people actually get angry that you use an old and stable version of the software, as those downvotes indicate.
At the SciPy 2017 conference, for the first time I saw speakers who were presenting new libraries say that they were not going to be developing Python2 versions. Quite a change from a year or two ago.
All my libraries have been py3-only since around last year. I'm also not caring much about supporting 2 on the old ones I maintain. 2 is pretty old, it's time to move on.
Why? Just because "it's pretty old?" The 2-to-3 change seems mostly cosmetic. When Python users ignored 3, Python devs started flogging their dead horse. When the horse still refused to move, disappointed riders started shouting "shame!" at users who suggested that the horse looked dead. Eventually, the riders tied ropes to the horse and pulled it along the ground. The onlookers either switched to bicycles and cars, or figured that they might as well ride the man-hauled carcass awhile longer.
Similarly, I'd always watch at least a handful of Pycon talks every year. Last year I couldn't really find anything relevant to Python2. The closest thing was and update on removing the GIL...but that was more informational than practical for me.
The text changes are type safety, but there are many more miscellaneous type safety improvements (like the default comparison between types (alphabetically by type name, except NoneType!) being removed, so now you can use set comparison operators with confidence) – plus support for type annotations.
It's a bit verbose. A lambda with a single one letter param takes ten characters to write: `lambda x: `. In JS, it's 5: `x => `. Ruby blocks take sevenish: `{|x| }`. Six in haskell.
I cheered Python's slow and steady 2.7 -> 3 move when it began but I'll admit I started to have some doubts a couple of years ago when it still had not completed. In hindsight I think it has been exceptionally well managed and is likely to keep Python in good stead for many years to come.
Their plan is more nuanced than "at the end of 2019". From a numpy feature standpoint, it's EOY 2018, bugs through EOY 2019:
> Until December 31, 2018, all NumPy releases will fully support both Python2 and Python3.
Starting on January 1, 2019, any new feature releases will support only Python3.
The last Python2 supporting release will be designated as a long term support (LTS) release, meaning that we will continue to merge bug fixes and make bug fix releases for a longer period than usual. Specifically, it will be supported by the community until December 31, 2019.
Readit News
For people wondering why it's been like this for almost a decade(!) since Python 3.0 was released: Python 3.0 was actually terrible. It lacked many critical things, and was riddled with bugs and security flaws until 3.3, which was released 4 years after 3.0. This cemented in many people's minds the idea that Python 3 was a bad thing. Python 2 was and is a fantastic programming language, so it was a very high bar to move up from. Python 3 has come a long way since then, Python 3.6 is now a decent step up from 2.7.
The only thing in the last decade or so of Python3's existence that even got me slightly interested in using it was asyncio, and after looking into it a bit, it frankly seems like more trouble than its worth.
I know Python 2.7 extremely well. It works perfectly fine for just about everything I use it for. It's STABLE. For the tasks I use it for, it runs faster than Python3... (Not that performance is my greatest concern when using Python.) So, please tell me -- why on earth is it a good thing that people are trying to kill off Python2? What exactly makes Python 3.6 a "decent step up" from 2.7? I'm still at the point of thinking, as you said, that Python3 is a bad thing.
Because the community is fragmented and that weakens language adoption, productivity, and enjoyment.
The 2-3 schism in Python has been a pain to deal with for years. I use Python casually here and there, but I'm so sick of trying to do something quickly in Python and finding out that I'm on a machine that only has 2 but the module I need is only for 3 or having the bulk of my app written in 3 but the only version of a module I need is for 2.
Same goes for examples you find on the Internet to do a particular thing. Ooops, it's 2.x syntax/modules so you have to fix it up for 3. Ooops, it's 3 syntax/modules so you have to fix it up for 2.
For the good of any computer language, old versions need to eventually die off.
It seems pretty clear now that 3rd party library developers are going to stop releasing packages that support 2.x and target only 3.x. Isn't that a bigger problem for Python 2.7 hold outs?
Originally, I was not super excited about Python 3. I liked "print" as a keyword. I liked the space efficiency and speed of latin-1 strings by default. I did a lot of network protocol stuff and bytes() was a pain to use. I knew how to use the 'u' prefix to get unicode when I needed. However, after using Python 3 for a few years now, I find Python 2 clumsy. Print as a function is better. Unicode works better. The implementation is just as fast or faster than Python 2 and getting faster every release. If you tried Python 3 a few releases ago, you should give it another go. It has matured a lot.
For example, print and division made more sense to me in 3, judging from friends who taught 2 and said those were always sticky for some students in every class. Intuitive lowers the barrier to entry. (But 2 is probably more intuitive to you because it's second nature to you by now.)
Unicode--when I would test some tiny scripts with Chinese characters or weird ciphers--was pretty easy out of the box in 3.
On systems that only support 2 I find myself slipping in basically a 'from future import all the things.'
These are admittedly mostly cosmetics. But cosmetics matter for noobs like I was, or maybe still am.
I guess 3 also fixed ambiguity in corner cases for error handling? Never came up for me so I don't know much about that one.
You probably just don't have those use cases?
Two people could use distinct subsets of python and neither is using it wrong. Meaning... there could be reasons many of us want 3 that simply don't apply to you. Which sucks, because you get hit with switching costs to help the rest of us.
I think that's the recipe for an endless debate with two reasonable sides.
I will say py2 was already fragmented without 3. PaiMei only ran on... 2.4 maybe? You'd find weird projects that you liked that would then get abandoned. Suddenly you're shimming them all or running four versions. I think 3 woke people up to this as a problem--by making it much harder to patch and way more universal. That made the project more conscious about future and backwards compatibility. Those dividends will only be seen over time. I hope they vest but can't prove how or if they have.
I hope this is helpful... Just know that I'm not saying you're wrong to want to use something that works for you. Switching costs are a real thing, I know it sucks to feel dragged along. But py3 is a lot better for me and others, possibly because we're using the language for different things.
Sure, you can continue using Python 2, and it's going to work for you. I guess you can also keep using Windows XP (no reason not to use it beyond the fact that Microsoft has gotten bored of providing security and bugfixes), and code using your PS/2 keyboard...
Generally speaking, Python 3 is actually faster now. I am a bit surprised that no one else has commented on this. There was a talk about performance recently (https://www.youtube.com/watch?v=d65dCD3VH9Q). To sum it up, some parts are slower and other parts are faster, and the reasons depend on two questions:
1: Is it using a lot of small ints? Python 3 changed int from being small int to long int, and for work which deals with massive amount of ints this will result in a slow down. If for some reason you want to use a pure Python implementation of AES rather than using hardware acceleration (generally builtin to the CPU) or a C implementation, or the one built in the linux kernel, then you will hit the performance test that get the biggest negative difference between python 2.7 and master. Then there is numpy which uses C modules that can happy do things as small ints.
2: Bytes -> Unicode. Libraries that are Unicode unaware will run faster than libraries that are Unicode aware. The feature to understand that "ö" is a Swedish letter and not several characters does cost some CPU time. For parsing where per character manipulation is relevant (like say HTML), such parsing will be a bit slower in python 3.
Practically everything else is faster now in python 3.
The language and the standard lib improved a lot. There are so many improvements, it would be impossible to list them all after so many years of progress...
Just to name a few of the bigger improvements, that I have discovered recently:
* The typing module lets you add type annotations to your code and write code like this:
* F-strigs are awesome: * I think asyncio and the async/await syntax are great.* The refactoring of the subprocess module:
* The documentation of the standard lib improved a lot, if you ask me.This is just off the top of my head...
But really, it's the overall improvement of the language and the standard lib that make the difference, not just the big features.
This typically means one of two things:
1. You've never really looked at the features added in the Python 3.x release series, or
2. You develop abandonware which plans never to upgrade any part of its platform ever, for any reason, and so no conceivable new feature would be sufficient to convince you to do an upgrade.
At this point (1) is untenable because of how many people have written about the useful things available in 3.x, and (2) is disingenuous (but there are still plenty of people who use "don't see a reason to upgrade" as an excuse for "I always planned to abandon this").
Just in case you're one of the people in (1), here you go:
https://eev.ee/blog/2016/07/31/python-faq-why-should-i-use-p...
docker-compose uses Python2 and has encoding issues on Windows that have no real workarounds other than upgrading to Python3: https://github.com/docker/compose/issues/2775
From a library maintainer POV, I do want to use Python 3. There's no one killer feature, but rather a bunch of small ones, like more specific exception classes (FileNotFoundError etc.).
But if you want to keep using Python 2.7, no-one will take it away from you.
I'm sorry if that seems mean, but in the grand scheme of things the differences between 2 and 3 are pretty trivial, and most people still complaining about this are just being stubborn. I refuse to believe somebody can know Python 2.7 "extremely well" but then also need more than ten years to learn the few areas where Python 3 is different.
If you want to get strong at network programming without spinning up on all the complex topics in async io (coroutines, futures, etc), you may like my networking system: github.com/solent/solent-eng
It is designed to allow the programmer to reason about exactly what the process is doing, rather than to hide things away.
The docs are not in great shape at the moment. Good starting points: the telnet client (in tools) and the snake game (demo package).
This was originally in python2. I moved because of subtle improvements in python3 packages over python2. But once I appreciated the string changes, I wished I had moved much earlier.
There are many minor improvements and new functionality that working with it is so much enjoyable and make code more readable and shorter.
I got to a point where it feels like a chore whenever I have to use Python 2.7.
It's a presentation by core developer Brett Cannon which explains what's better about Python 3. The list is quite long for an HN comment, so I'm not going to repeat it here.
Now it's pretty dated as there had been more things added like async, so Python 3 is even better now.
Anyways, I haven't been running into issues with Python 3 recently and I use it as much as I can.
Python 2.7 has just about the worst unicode handling of ANY language I've ever used.
Plenty of otherwise crappy languages (Java, JavaScript, etc) managed to make one right choice when they decided that strings are always unicode and bytes are a different data type entirely.
Also, the asyncio implementation in Python 3, while a bit complicated, is on the whole very nice, providing a lot of flexibility.
Long story short, if you still think Python 3.6 is "bad" in this day and age then you need to move on to another language.
Proper handling of Unicode, and more sensible distinction between bytes and characters.
Seriously, Python 3 has done that _so well_ that I wish other languages would take notice.
https://news.ycombinator.com/item?id=12930793
https://docs.python.org/3/whatsnew/3.6.html#pep-498-formatte...
Dead Comment
Python 3 solves a lot of problems for me, as someone who does a lot of NLP work, and generally has to deal with strings from the outside world and multiple languages and all that on a more-or-less constant basis. I imagine it solves some problems for Web developers, too, though possibly to a lesser extent. But I don't see a whole lot of devops people being eager to jump off of Python 2, and I'm not sure I see it solving more annoyances in that domain than the process of migrating to Python 3 would create, either.
The only one that comes to mind for me is fabric, to be honest.
Right now 187 of the top 200 packages on Pypi support Python 3. https://python3wos.appspot.com/
Speaking of Fabric, does anyone know of any Python 3 projects similar to it? I've been using Fabric3 since the switch but it's not a 1:1 port. I'd consider dropping it in favor of something better if it exists.
Searching for code snippets and copy/pasting stackoverflow answers can easily take more time out of my days than library documentation. But it's so much slower when I have to rewrite something I found for python 3.
Almost every time I tried to use a library, it was 2.7 only.
That situation has only changed recently, and with it people have moved on to 3. (Which sort of underscores that the library support was the main issue).
Widespread adoption of Python 3 would've happened years earlier if you could start a new project in Python 3 and not have to worry about libraries you want to use not supporting it yet.
For some tasks, there are literally 5 mutually incompatible syntaxes to understand (Obj C, Swift 1234). Even though the UI can sometimes autoconvert for you, it doesn't help at at when you're looking at someone else's code.
Swift is a great example of what not to do.
And Django 2.0 should come out December 1st, so it’s not far off.
There are gargantuan Python2 projects out in the wild which are expected to continue, and can't realistically be migrated to Python3. In 15 or 20 years we'll be looking at those jobs the same way we look at Perl jobs today.
http://portingdb.xyz
(Red Hat has been one of the primary maintainers of Python 2.7 in the last few years. https://news.ycombinator.com/item?id=7582300 )
The BSDs on the other hand (including MacOS) "run on" Python 2 and haven't made as much progress switching to Python 3.
Put most concisely, it's something like "making the most common use case as easy as possible can make slightly less common use cases wrong, dangerous and hard".
It's not an out of touch academic committee making these changes out of ignorance or spite. It's people who have to support more use cases than yours. Even if yours is the most common, that doesn't mean that the rest (internationalization, binary data transfer) are distant, rare outliers, or that the frequency of non-traditionally-"simple" ascii text handling applications isn't changing.
So, what is it exactly that you're trying to do?
Funny, I found the exact opposite, and despite $dayjob being LCD(2, 3) and the default Python on my system being 2, I've been writing all my small scripts in 3.6.
As a library writer, I cannot wait until we get rid of this self-inflicted handicap of writing in a subset of two incompatible languages. I'm glad the heavyweights are joining the cause.
Even though the transition from 2 to 3 has been slow, I take it as a positive sign about the Python ecosystem. The general Python community has traditionally erred toward stability, and conservative feature introduction. The gradual introduction of large changes to the core language reflects that characteristic.
Hopefully this will cajole Python 2.7 users to migrate. Assuming you have decent test coverage, the migration generally isn't that difficult.
If you do a lot of NLP or string processing, the sane unicode support is worth it alone.
Kudos to the numpy team for writing the most awesome python module under the sun, and for providing great support!
Why? Just because "it's pretty old?" The 2-to-3 change seems mostly cosmetic. When Python users ignored 3, Python devs started flogging their dead horse. When the horse still refused to move, disappointed riders started shouting "shame!" at users who suggested that the horse looked dead. Eventually, the riders tied ropes to the horse and pulled it along the ground. The onlookers either switched to bicycles and cars, or figured that they might as well ride the man-hauled carcass awhile longer.
(I'm still stuck using Python2--not by choice)
All that time for Unicode. Not concurrency or type safety or static guarantees or better lambda syntax or anything fun like that. Just Unicode.
The text changes are type safety, but there are many more miscellaneous type safety improvements (like the default comparison between types (alphabetically by type name, except NoneType!) being removed, so now you can use set comparison operators with confidence) – plus support for type annotations.
What do you mean by better lambda syntax? Is there something that you feel isn't adequate in the current syntax?
I guess it's due -- Python 3 finally has some improvements to the runtime that I think will start to pull more Python2 people over.
> Until December 31, 2018, all NumPy releases will fully support both Python2 and Python3.
Starting on January 1, 2019, any new feature releases will support only Python3.
The last Python2 supporting release will be designated as a long term support (LTS) release, meaning that we will continue to merge bug fixes and make bug fix releases for a longer period than usual. Specifically, it will be supported by the community until December 31, 2019.