Except it kinda is the current version to lots of us. I moved to Python as a hobbyist from .net languages and loved the freedom of not having an IDE and working with Linux. The first decent book I read was on Python 3 so I learned Python 3. Lots of us 'newcomers' (not so new in my case) learnt on Python 3, find perfectly good library support in Python 3. In fact the 'old guard', sound a bit like my Dad talking about how old cars or pre decimal currency to me. I just don't find myself hitting problems I can't solve on Python 3, that I could have solved under Python 2. To be fair I have a pretty minimal amount of code in production, but in each case it is not so monolithic that I couldn't have some of it using Python 2 and some using Python 3 or even some other language for that matter.
Python 3 is not only the future but the current version of Python. It is the version kids learn in School (in the UK kids do some CS from the age of 6 or 7, starting on scratch and then normally Python), it is the version colleges teach.
However there are lots of reasons enterprise users may want to use a legacy codebase. It is not like Python 2.7 is about to stop working! When a section needs a major re-write, then consider porting it. I don't see how this is different to any obsolescence problem. I know an enterprise software company that wrote a lot of stuff in VB6. Some of it is still in VB6 and they have to manage everything that means (especially around 64 bit architecture problems), when they do major updates they use .net. How can we be in the technology game and not just except that life moves on!
The fact that there's a huge split in the community over the issue shows just how divisive Python 3 is. That said, 3 > 2 in version number doesn't make it better or more "current" (and I've seen a number of projects where the "latest" version wasn't even the latest - it was often an experimental). Yes, you could do just about everything you need to in Python 3 that you can do in Python 2, except that it can be much more difficult depending on what you're doing.
e.g. this guy -> http://lucumr.pocoo.org/2014/5/12/everything-about-unicode/
I found it's easy enough to add the line:
# -- coding: utf-8 --
to the top of my Python 2 files so I can get UTF-8. That, and Python 2 has the bindings for GTK (which I like to use).
Both versions of the language have their usage, and to each his own. There's no sense in bickering about it.
I do think the split is in use-cases. I've worked in film at both small and very large places. You can get by very easily ignoring things like color management and frame rates when you're doing small, homogenous work. As soon as you need to take it seriously, the only real way to handle these things is to tag and/or convert these things at the perimeter so you can reliably handle things internally in a consistent way, then convert on the way back out. Even knowing this upfront and being highly motivated, it can take companies years to transition with pain in the meantime.
Text handling is the same. The thing is, many people just deal with ascii compatible English so they don't realize this is a problem for other people and aren't motivated to change. The reason both sides can't just do their own thing (i.e. Python2) is because of libraries and shared code makes it miserable for people using other character sets (most of the world or any company growing bigger than a certain size).
Indeed. One has to wonder, then, about the controversial nature of Python breaking backwards compatibility for the sake of improvement. People are down on "Python 2.8" for changing the name, but the fact that there is no standard set-in-stone led to these problems to begin with. People want a reliable standard, so are the authors at fault for breaking that implied standard and carrying the name with them? Should they have changed the name to PythonU? Or do we always defer to the author's right to change both the VM and the implied standard at will? It's a human-party-pleasing problem because the changes obviously hurt some people (those having to rewrite libraries, which may be easy or very hard and time consuming) for the sake of helping others (who would have time-bomb buggy programs in 2). shrug
It's worth noting that Microsoft is still keeping VB6 on life support, in a sense. The tooling is not guaranteed to work on modern OSes (and there is a bunch of actual breakage, although community has found workarounds so far).
But the runtime is still supported - in fact, it ships with the OS! If you have any non-ARM version of Windows, up to and including Win10, around, check the file named msvbvm60.dll in C:\Windows\SysWOW64 - that's it ("MS VB VM").
And because it ships as an OS component, the official support policy is the same as the rest of the OS, which is at least 5 years of mainstream support (longer if there's no successor release), and then at least 5 years of extended support. This is even clarified specifically for VB6:
Since VB6 was first released in 1998, this marks 18 years of continued support to date; and if it's not dropped from the OS within the next 2 years, it has a chance of hitting 30 years...
For what it's worth, PSF also has a fairly generous (especially for a non-commercial OSS project) support policy for Python 2.7 - it had already extended the end-of-life date for it once to 2020:
That's the gamble you took when you chose to go all in on Python3. I personally didn't buy the arguments made and chose to stick with Python2. If I migrate anywhere, it would be to a Python2 compatible fork or something like Go.
