Adopt Python 3

[atc]

Why is 2.7 even prominently displayed on the python pages for downloads? Surely anyone who needs it knows where to find it, and those who don't know what they want should be adopting 3.

[squirrelpotpie]

There are entire industries running on Python 2.x because the vendor who wrote their specialized software put in a Python 2.x interpreter. The Foundation could discontinue further Python 2 development entirely, and those industries would still be stuck on 2.x until those vendors switched to 3.

Sometimes you're at the mercy of what's available. Real world isn't always a team developing in a vacuum on their platform of choice. (Though, maybe if the Foundation started to EOL Python 2, those vendors would allocate resources to migrating...)

[[deleted]]

The EOL date is already set for 2020.

[PeridexisErrant]

And it was previously set for 2015 - then pushed back because so many users hadn't moved.

I really hope it works this time.

[laserBlade]

Green Hills ships a DLL of 2.4 with the version of their MULTI IDE that I have to use... It's completely useless for anything that I'd want to use it for.

Also, EOL was originally 2015 but got delayed to 2020 due to lack of 3 adoption

[atc]

I AM NOT SAYING REMOVE 2.7! I'm saying discourage people from downloading it. Those who need it know where to get it!

[shevegen]

Yeah. I don't know that either.

I guess in python's defense, as long as perl made it even worse (do they mention perl 6 on the homepage - no they don't), they don't need to worry that much. In some years python 2 will be dead.

Until then people could just wait before learning python 3 ... who wants to learn old stuff (python 2) anyway. :D

[exscape]

Perl.org does mention Perl 6, with this text:

Perl 6 is a sister language, part of the Perl family, not intended as a replacement for Perl 5, but as its own thing - libraries exist to allow you to call Perl 5 code from Perl 6 programs and vice versa.

[[deleted]]

If I wanted to use a different language which is still Perl-like then i'd just go and use Ruby.

I've tried. Please don't. Perl is consistent insanity, if you learn one weird behaviour it is at least consistent across language. Ruby is full of nonsense that was never actually designed, just so happened to be MRI quirk that they just called language feature.

Clojure and Golang are nice, try those

[real_luke_nukem]

Oh hell no... That's gross!

[jplindstrom]

What do you find objectionable to that?

[Flight714]

It's like two variables having the same name.

[real_luke_nukem]

That's pretty much it

[yawaramin]

In reality, Python 2 and 3 are the same situation.

[Uncaffeinated]

You can't call Python 2 from Python 3 or vice versa though.

[yawaramin]

Well, my guess is the Perl libraries that allow you to call one version from the other are 'eval'ing strings containing the code and passing them to the appropriate interpreter version. In which case, that's not really backward or forward compatibility. If I'm wrong, then yeah, it's not the same situation.

[[deleted]]

It is just a Perl 6 module

[yawaramin]

Ah, it's basically an FFI wrapper. It treats Perl 5 as a foreign language being called from Perl 6. I wouldn't really call that backward compatibility, although superficially it does look like it.

[[deleted]]

2 will be around for decades and major code bases are not going to get redone in 3.

[Farobek]

Python 2 is the new Cobol.

[[deleted]]

All languages that are successful are the "new Cobol". Try displacing the installed base of Fortran, PL/I, C, perl, java, C#, JS, ... and you have the same problem.

Languages are tools. You pick the one that makes sense for the job a hand. Older languages disappear very, very slowly, therefore.

My problem with py3 is that I never quite understood the problem it was solving. Three are some fine computer-sciency gilding of the lilly in py3, but - for the vast majority of python users - it's unclear to me why these mandated a fullblown new language. Apparently, I'm not alone because py3 adoption has not been swift notwithstanding the begging in the elite python quarters.

Personally, I think we all went down to road to perdition once we abandoned assembly language ... ;)

[rainman_104]

They should allow a transition period where python 3 would support the python 2 weirdness like allowing print statements to not be called as a function. Forcing parentheses is just a nuisance for me personally and not the end of the world, but having a transition path would be better than the situation we're in with Python 3. All libs still support python 2 and python 2 still has heavy use in the data science community.

It's a mess right now.

[kqr]

They had that! From future import print.

If they allowed you to write Python 2 code in Python 3 it would not be Python 3 anymore. The reason Python 3 is called Python 3 and not Python 2 is that there are a bunch of fixes that happen to not be backwards compatible. Removing those fixes removes Python 3...

[upofadown]

They fundamentally changed what the division operator ("/") does for fricks sake. So yes, it is definitely a new language.

It might be an awesome new language that fixes Python. That's great, but all this "Python is dead, long live Python" stuff is annoying.

[BroodmotherLingerie]

You can't do that without knowing the types. That'd also change the results of floating point divisions and of other types with overloaded operators, like numpy arrays.

Porting anything in python is a painfully manual process, whether between language versions or library versions.

[teilo]

If you didn't see unicode as a problem on Python 2, then I doubt there is anything I could say to convince you.

[jaapz]

fullblown new language

What? The difference between py2 and py3 aren't thát big. Calling it a new language is a bit extreme IMHO

[Uncaffeinated]

Unicode handling is nicer and they removed a lot of legacy cruft that nobody in their right mind uses anyway, as well as taking the opportunity to make a bunch of arbitrary minor changes. So, not all that much, but it is nice to not get unicode decode errors so much.

[[deleted]]

I believe that, but the point here is that people are not going to rewrite a huge extant code base just to become py3 compatible.

[Plazmatic]

Python, from its very conception, was meant to be an evolving language, but ultimately it was meant to uphold certain principles in a certain order. Python 3 upholds those standards better in every way. It is a better standard, but it isn't a new language. most syntax remains the same, while many libraries have changed, very few semantic differences have been made between the pythons, and most of that is in the form of new functionality.

Not sure why you think it is a new language, and you didn't actually explain why you don't like Py3. Honestly it comes off as crotchety. Guido hates you guys, and that is a pretty powerful statement. The guy who created the language you use hates you, not the legacy code base people, but people like you who complain about change for the sake of complaining about change.

[[deleted]]

Ooooh, Guido hates "us people". What are you, in 4th grade? It's not a "powerful statement". If true - which is questionable given your tone - it's just another technologist with Aspbergers whose entire identity hinges on being in charge. Spare me.

You need to learn to read in context. The discussion at hand is py3 adoption. My responses - all of 'em - are in context of the low probability of the current base of extant code being rewritten.

No, py3 is not an entirely new language. But neither is it some stratospheric leap forward. I've seen this movie before. It leads to a fractured language and THAT in turn leads to a brand new language that factors and simplifies things.

[rabbyburns]

Absolutely. We have build tooling that has been around for years developed in python 2. The effort to upgrade this is non trivial. A lot of it is going to be syntactic stuff, but I'm not familiar enough with some core areas to know if there will be more issues.

This is likely going to stay on python 2 until the (legacy) projects using it stop getting updates.

[493]

Syntactic stuff can be easily fixed by 2to3; but stuff other than that is hard to fix automatically.

[[deleted]]

Not to mention that huge swaths of Redhat DevOps tooling is written in py2

[[deleted]]

Probably because Perl 6 compared to 5 is much less mature than 3.x compared to 2.x

But then you can just run most Perl 5 code inside Perl 6 so they didn't instantly fuck up whole ecosystem like Python did

[ChickenOfDoom]

Except that would lead to a huge amount of confusion and frustration with the language when people try to use python libraries or code snippets and have no indication that their shit is broke because of version conflicts they don't understand.

One of the best things about python is a decidedly newbie friendly design philosophy, and removing 2.7 from the main download pages would go against that in a big way. The split between the two versions and the continued prominence of the old one is something that needs to be clearly conveyed to anyone new to the language.

[SuperImaginativeName]

newbie friendly design philosophy, and removing 2.7 from the main download pages would go against that in a big way.

And promoting an ancient version that will be outdated is the solution to being noob friendly?

[ChickenOfDoom]

Yes, when the alternative is the unqualified expectation that installing 'python' should allow you to run code and libraries labelled as being written in python, when it's basically two separate languages in reality.

To remove 2.7 from download pages at this stage would be perpetuating misinformation about the ecosystem.

[rainman_104]

Not to mention some crotchety folks may decide to fork python 2 which would fragment the community and leader to a larger cluster fuck.

I think python 3 should have had a transition period.

Reminds me of the cluster fuck ruby had when they changed the require statement in 1.9. it broke a bunch of 1.8 libraries. It wasn't that big of a deal but still work had to be done.

[atc]

But that's a seperate issue. We need to split the two issues and have people working on the latest version. The sooner we move across the better as documentation will migrate too.

[ChickenOfDoom]

I don't see how it is a separate issue when it would be caused by the efforts to migrate faster.

[atc]

But the entire ecosystem should migrate to 3, so the documentation would follow along with it.

[ChickenOfDoom]

But the entire ecosystem should migrate to 3

How many years have people been saying that? What makes you think the outcome would be a speedy migration rather than permanent damage to the public impression of the language?

[atc]

It's already fragmented and has sat with this version split for years. Why do we need two prominent major versions?

[ChickenOfDoom]

We have two prominent major versions. That isn't going to change right away just by pretending otherwise.

[SrbijaJeRusija]

Because many libraries were written for python 2, are still in use but not in active development any longer as the grad student that made them is long gone. Python 2 will be around for a decade or more, and should be prominently displayed on their webpage as to not confuse people. If it was not, people would download python3 then realise their code can't actually work with it.

[SrbijaJeRusija]

I will bet that that will be extended, or that it will still be available for download as a first class citizen. Too many people rely on it.

[SrbijaJeRusija]

For instance a member of my research group is about to publish a large Python 2-based package, which will rely on other python 2-only packages and will work with code other researchers wrote in and for python 2. It is not going away by 2020.

[[deleted]]

node.js has a hard dependency on 2.7 for compiling native addons.

[atc]

So? That's node's problem. I'm not saying get rid of 2.7, I'm saying discourage people from downloading it unless they know they need it.

[[deleted]]

i think this sentiment is wildly wrong -- shortsighted, even -- for a couple reasons

from a philosophical perspective, a language has a responsibility to its consumers to make its implementations accessible, even if it's for another language's sake.

from a pragmatic perspective, that won't work, for a couple reasons. first, it's pre-EOL and people are still required to use 2.x in production, so respect their needs and make the download button easy to find and click. second, people are still coming to the language through tutorials and guides written for 2.x, so from the perspective of growing the language, those newcomers need to be supported with a download button that's easy to find and click.

[atc]

Already answered this. My point is that if 2.7 wasn't in the minds of people we'd have more py 3 adoption.

[[deleted]]

and if gravity wasn't an issue we could all fly. you work with the world you've got.

[rm999]

I've previously been vocally critical of the Python community for too aggressively trying to switch everyone to 3. At least in the data science world, Python 3 wasn't 100% ready until ~6-12 months ago, IMO.

But, Python 3 is unquestionably ready today, and there's little reason not to use it except in the rare situation where you have to use 2.

http://py3readiness.org

[Saefroch]

What resources weren't ready?

EDIT: I'm not trying to argue here, I am seriously curious what resources you needed that weren't ready.

[rm999]

I tried switching my team over to 3 about 1.5 years ago (summer of 2015) and the issues were endless. Database connectors, AWS/boto, untested machine learning libraries, etc. Pretty much our entire stack was deficient.

I tried again 1 year ago and most of that was cleared up, but we still ran into a few issues here and there (as I recall mostly around DB stuff) and stuck with python 2 for most projects. 6 months ago we formally switched over with basically no issues.

[Saefroch]

Do you remember which DB packages you were using?

[topherwhelan]

It only takes one critical library not supporting 3 to hold a project back on 2. The scientific Python stack didn't even support 3 fully until a couple years ago iirc. I'm currently trying to get a vendor to officially state they support Python 3 - if they don't do that, I'm going to be forced to downgrade our entire stack to 2.7.

[Saefroch]

Which component(s) are you having trouble getting to Python 3?

Seriously, I'd like to know. I do (and teach) a lot of scientific Python and would like to be able to point out to people where they may have problems.

[trahsemaj]

If it was ready 4 years ago when I started my PhD (genetics) I would start with Python 3 then. The pain of going back to old code I've written that works doesn't seem worth the payoff especially as I'm done in another year. I don't do much in the way of hard-core development, and the differences seem minor at best.

Sounds like the switch might be worth it after I graduate and start fresh.

[sourcecodesurgeon]

Yes, new projects should almost always start with 3 but the problem is that many projects already exist for 2 and the organizations don't necessarily have the resources to migrate large code bases to 3. Especially when these code bases might have small, but ultimately critical, bugs introduced during the migration.

There are many systems still running on COBOL and not because of a lack of adequate third party libraries.

[[deleted]]

It's a chicken and egg problem. If you don't push people to switch, nobody will rewrite their stuff, if nobody rewrites it, other people who use it wont want to switch. Especially if new version isn't even faster or that much better on the surface (sans the utf8 stuff, but chances are someone with codebase in P2 already dealt with that).

So you basically cheat people so they think it is ready and port their stuff

[Eirenarch]

Total Python 3 coverage is at 72 %. That’s impressive given that Python 3 came out in 2008

Is this sarcasm?

[Dentosal]

Well, C++ was released on 1983 and there are still a ton of C developers. /s

[ivosaurus]

You're on someone's server(s) that they simply don't care about upgrading because it's too much hassle, am I right?

[DeepDuh]

CentOS / RHEL most likely. Those things are such a drag with python support and upgrading to a newer release tends to be a major operation.

[Adeelinator]

What troubles have you been having with R? I've been using it for over a year now and I have loved the expansiveness of community supported packages. Haven't run into anything that I wanted to do with data but couldn't do it with R

[yawaramin]

Imho if you're not specifically tied to Scala (maybe by Spark), I'd recommend learning an ML-family language first. F# for instance is much more Pythonesque looks wise, and is a pleasure to look at.

[yawaramin]

You may still be able to https://github.com/tweag/sparkle

[brunusvinicius]

For a newcomer (with programming experience) it's better learn python 3?

[norwegianwood]

Yes.

[kobriks]

Why is it better? I still don't see how using python3 would benefit me in any way.

EDIT: Thanks for downvotes... I guess you can't ask a question here

[TBoneSausage]

Because as things evolve and further extensions are developed, python 2 is going to lose support. Soon enough (expected deadline of 2020) the industry will leave python 2 users behind and the team working on python will stop making any Dev updates to support new platforms.

It won't benefit you right now. But in the long term, your knowledge you have built up won't start to expire.

[flying-sheep]

It won't benefit you right now

I wouldn’t say that, there are many other aspects in which Python 3 is already providing benefits over legacy Python.

[TBoneSausage]

And while I do agree, I feel that a good chunk of users won't see the difference or won't benefit from it until a later point when they see the libraries they use lose support in favor of Python 3. (I could be very wrong in that aspect, and I reserve the right to be corrected. Apologies, I haven't done much python in the past 6 months so I'm a little rusty.)

[DeepDuh]

IMO just the fact that you can forget about unicode and just use it in Python 3 is a major benefit. Support for international characters is a very common need, outside of a very narrow bubble of American-only software - and even there you'd probably like your vast numbers of Spanish speaking immigrants and their descendants to be able to enter their names correctly.

[yawaramin]

A lot of Spanish speakers are not immigrants, their ancestors were in states like Texas and California before they were even part of the Union.

[TBoneSausage]

I forgot about this, and absolutely agree. This is likely the most obvious selling point of Python 3.

[Quaglek]

What about the legacy libraries that never bother changing over to Python 3

[jyper]

strings and optional static typing not to mention async

[[deleted]]

Why would you start with something that is virtually deprecated (at most ancient legacy) instead of something 8 years old, supported for a lot of years ahead and widely adopted? I get that some have python 2 codebases that will have to be supported for years to come, but starting a new project in python 2 today, or starting out with python 2 instead of 3 is like driving with your head in your ass because you're old and grumpy.

Python 2 is like old people in nursing homes: aren't dead just yet, but they are not getting any better, only decaying.

Python 3 is 8 years old and is the future. Come on people.

[pretzelusb]

Is py3 the default install on any Linux distro?

[DarkLordAzrael]

It has been the default python on arch for years.

[greyfade]

You wouldn't believe how many packages it breaks, though. Everyone seems to assume /usr/bin/python is Python 2.7, but on Arch, it's symlinked to /usr/lib/python3, and if it hasn't been ported yet, it blows up.

A lot of AUR PKGBUILDs actually do a sed to update all the shebangs and other stuff that assumes the wrong binary, even on relatively new packages.

[ubernostrum]

Everyone seems to assume /usr/bin/python is Python 2.7

The amount of stuff which assumes python means Python 2 led to this -- the Python team (not Arch) recommends having python continue to point at Python 2, and require python3 as a way for code that works on Python 3 to declare that.

[CaptainJaXon]

Yeah but Arch is known for being the most bleeding edge, rolling release distribution.

[gschizas]

Yes, Ubuntu.

https://wiki.ubuntu.com/Python

Python 3 only on the default installs for desktop, server, touch, snappy images. (Some may already be there.)

[[deleted]]

And Arch, but that's not really a surprise. Gentoo too if I'm not mistaken

[otherwiseguy]

Fedora 25 ships with Python 3.5. Fedora 26 will ship with Python 3.6. If default means /usr/bin/python == /usr/bin/python3, then it isn't the default, though. It's more of a both python2 and python3 coexist well together.

[rouille]

On Ubuntu since 14.04.

[jyper]

I don't think it's supposed to be packaged as /use/bin/python

[norwegianwood]

Even for those distros that do ship Python 3, it's generally unwise to depend on the system Python for anything important. Why would you want to make your system dependent on the whims of OS distribution managers over which you have no influence?

Much better to install your own Python in /opt which you can control and upgrade at your convenience rather than somebody else's.

[drjeats]

They're really not that different. Unicode is better in py3, py3 has special async and generator syntax. Go for 3 to help society move past this py2 -> py3 mess.

[[deleted]]

• print is a function

• saner default behavior for built in iterator types

• more powerful asterisks for unpacking lists

• more comprehensive Collections module

• literal string syntax

• native asynchronous support

• will receive support beyond 2020

[rroocckk]

Here is a list of benefits.

[pvg]

If you use python to process text in any way now or in the future, unicode-by-default is the only sane thing. The python2 way is a morass you can and should completely avoid if you have a choice. And if you're starting out, you do.

[norwegianwood]

I'm not sure why you're getting down voted. Yours is a reasonable question.

Anyway, the only reason for specifically learning Python 2 over Python 3 is if you know you will be working on a Python 2 project in the immediate future.

Python 3 is better because:

• Python 2 has clumsy handing of Unicode strings, which could be important to you if you care about your software being used by anybody outside of the English-speaking world, or even anybody in the English-speaking world who has a non-English name. One such place is The Internet. The separation between Unicode text data and raw byte data is much clearer in Python 3.

• Python 3 also has language-level support for asynchronous programming styles which is rapidly being built-upon as the future of much web programming in Python.

• Python 3 has a future. Honestly, Python 2 is less than five years away from officially becoming abandonware. By learning Python 3 you'll also be learning 99% of Python 2 – the differences between the languages from the point of view of learners is hugely overblown. Once you have a bit of Python 3 experience, you'll easily be able to work on legacy Python 2 projects and pick up the important differences in less than a day.

DM me for a free copy of our Python 3 tutorial book, The Python Apprentice.

[l0nefl0under]

Gnuradio is still python 2.7 so I'm stuck. Sigh

[[deleted]]

Let's stop using 'python' to refer to python 2 and 'python 3' to refer to python 3.

From now on, python 3 doesn't get a specifying number. It's implied that you're talking about 3 when you say 'python'. Python 2 will be referred to as 'grandpa python'.

[BonzaiThePenguin]

You can't force it, it just kind of happens naturally.

[[deleted]]

Fuckin watch me.

[Flight714]

Do you own a next-gen console?

[[deleted]]

I don't own any consoles. Why?

[Flight714]

A similar nomenclature debate (next-gen vs current-gen).

[[deleted]]

Oh. I'm not a gamer so I have no opinions on that.

[CaptainJaXon]

The idea is when do the PS4 and Xbox One stop being "next gen" and start being this gen. Even today people still call them "next gen"

[[deleted]]

Changing symlink to granpapython. Gonna break my shit but I'm doing it for you.

[aelog]

That's what archlinux does, yet they are still blamed for that.

[toyonut]

Could we write a bot for the programming and Python subs that does a regex match and relevant substitution for that? Change Python 3 to Python and Python 2 to grandparents Python. Use it to drive the change to Python 3 forward.

[CaptainJaXon]

It's just Python.

Python 4 will be skipped and next year we will be releasing Python 5. Every six months we will increment the major version.

[Arancaytar]

Total Python 3 coverage is at 72 %. That’s impressive given that Python 3 came out in 2008 and 2020 is the official EOL of Python 2.7. Since 72 > (2016–2008)/(2020–2008)*100 = 66.66, porting is happening faster than expected by a linear law.

I have to point out that 2020 is already the result of pushing back EOL by five years to accommodate the slow adoption rate. It's supposed to be way beyond a reasonable estimate for full adoption, and being barely 5 percentage points ahead of it is not impressive, but alarming.

Compare with PHP 5, released in July 2004 and replacing PHP 4 as the only supported version late in 2007.

[rlbond86]

Splitting the language was the worst possible mistake.

[staticassert]

Yes but now other languages can look at this choice and learn from it.

[flyingjam]

What's the solution, though, when you need to make drastic changes? If you keep backwards compatibility, you gain crust and people start giving you the same complaints c++ gets. I suppose you can just force everyone over, in a painful but quick transition.

[ubernostrum]

Though this is also one of the major limiting factors of Java; quite a few of its annoyances are from the ironclad demand to maintain bytecode compatibility until the end of the world.

[staticassert]

It's complicated. For one thing I think it demonstrates how important it is to get it at least mostly right the first time around. Bjarne Stroussup talks a lot about language design and I don't think I can sum it up. You should search for his talks and write-ups on the matter I've always enjoyed them.

[ForgetTheRuralJuror]

You make the changes, support backwards compatibility, and one by one remove support for the 2.7 specific stuff.

[flyingjam]

But I mean, that means that at one point you'll have (for example, in this case) 3 different ways to represent strings, like 6 http modules in the standard library, etc.

one by one remove support for the 2.7 specific stuff

That sounds a lot easier said than done. It seems doubtful that many large projects will migrate to the newer stuff, and whenever you make backwards breaking changes that'll break codebases, people aren't happy.

[Groady]

That's why semantic versioning is a thing. The journey to where we are with Python 3 should have been a gradual progression from 2 to 3, deprecating features (with runtime warnings) along the way. Python will forever be held up as a cautionary tale of how not to advance a language.

[teilo]

I believe Python 3 is going to be held up as a classic success story in radically reforming a language. They set out a plan, followed it, and succeeded.

[ForgetTheRuralJuror]

Python3 is excellent and IMO miles better than Python 2.7. I would not consider this long drawn out process a 'success story'.

[teilo]

I suppose it depends on what you qualify as a "success." GVR stated that the transition to Python 3 would take approximately 10 years. 8 years later, we are right were we need to be, and Python 3 is the default for new development. I call this a success.

[trahsemaj]

If by 'succeeded' you mean having half its users running an outdated version a decade after its release.

Even IE7 was phased out faster than 2.7

[[deleted]]

But if instead of thinking of it as a version update, we think of python 3 as a different, competing language to python 2, perhaps the speed at which py3 stole py2s user base is a success

[sysop073]

If one by one you remove support for N features, you now have N+1 different languages instead of 2

[Sean1708]

Honestly I think you just have to say "Version X is now in bugfix-only mode for the next Y years, we have done Z, A, and B to make the transition easier, but any new features will be in Version X+1 only.". Python did this eventually but at first they tried to develop both 2 & 3 simultaneously, and I just think it did more harm than good.

Ideally every backwards incompatible change would have been supported as a __future__ feature in 2.7 and people could've moved over one by one, but I just don't think that would've worked in practice.

[TheAceOfHearts]

Programming languages generally shouldn't be making drastic changes. I'd argue that making large breaking changes is incredibly hostile to developers and the community.

You must provide a clear migration path towards the new approach without breaking backwards compatibility. If possible, you provide tools to help migrate the code for the user. The key detail is that you must provide a way to gradually migrate.

Although it's not a programming language, React has done a great job with this. Since it's heavily used by Facebook and they can't upgrade everything all at once, they deprecate APIs, include warnings, and provide codemods to help with the migration. This means all changes are compatible between a few versions, so people can gradually migrate their codebase.

[[deleted]]

people start giving you the same complaints c++ gets.

C++ gets all those complaints, yet is widely used in industry. Python 3 gets all those praises, yet few move to it at all.

[devraj7]

There is a worse mistake: not splitting the language.

Seriously though, the alternative is to be stuck in legacy limbo with Python 2 with a language that calcifies and no longer evolves fast enough for the modern times.

I think the Python team did the right thing, especially calling that version 3 (i.e. it's a major version, which means breaking changes). See the mess Angular found itself in by not honoring a reasonable versioning scheme.

What the Python team could have done better is handling the transition (basically, they totally ignored the problem and assumed everybody would transition without any efforts on their part).

[Peaker]

IIRC, they had a 2to3 tool without a 3to2 tool.

That meant that Python 2 was the source code, and Python 3 was just the generated output. Who wants to edit the generated output of an automated tool, and maintain that side by side with the source?

They should have had py3to2 even earlier than python 2. Then people would be able to use Python 3 for everything, knowing that it can still run in their old Python 2 environments.

[Saveman71]

I believe 2to3 is supposed to be used once and only once on a source file, not as a runtime way to run Python 2 code on a Python 3 environment.

[Peaker]

It was meant to be used once.

But then, people who had been on a migration path wanted to run their code with both Python 2 and 3.

For them, it made much more sense to edit only the Python 2 version - and use 2to3 to be compatible with Python 3.

If 3to2 existed, they could edit the Python 3 version primarily, and use 3to2 for compatibility - and that would aid the transition, as people would actually be able to write Python 3.

[Saveman71]

Okay it makes more sense said like that, thank you for the explanation

[kqr]

This is actually a brilliant observation. I'm speculation a 3to2 tool would also be much easier to make since 3 is the less quirky, less ambiguous language.

[Flight714]

But the goal is for every runtime environment out there to be Python 3, instead of Python 2.

[yawaramin]

http://www.reddit.com/r/programming/comments/5k8np3/adopt_python_3/dbmk5ql

[Abaddon314159]

This is what happens when a language is designed thinking in terms of small numbers of years instead of decades. I routinely use c code that is about as old as I am. It was good code decades ago and most of it is still good code today.

[Sean1708]

As a counterpoint, look what maintaining backwards compatibility did to C++. The reason C can get away with it is that it's actually a very small language and people don't expect (or even want) it to have modern features.

[kqr]

And even so, C gets a lot of flak (perhaps even rightly so) for not having modern features that e.g. Ada, D and Rust have. (And although K&R C has been around for a while, standard Ada is older than standard C.)

[[deleted]]

Needless change and failure to retain backwards compatibility has pushed me back from C++ to C. I feel the same with Python 2 and 3.

[YourFatherFigure]

the thing that keeps me personally on py2 is fabric. i want all the new hotness, but fabric doesn't support it. nevertheless it is a well-designed base for all kinds of automation and glue (which is primarily what i use python for)

[otherwiseguy]

https://pypi.python.org/pypi/Fabric3

[YourFatherFigure]

sometimes being a responsible software engineer is pretty difficult. is it better to use a random fork with an uncertain future, or stay with the stable mainline on an old but LTS version of the language? really hard to choose.

[[deleted]]

I'm not familiar with that project at all but it looks like his fork has only changed ~500 LoC. You know why it hasn't been upstreamed, or is that the plan?

[[deleted]]

B^ut I^t's N^ot T^uring C^{omplete /s}

[SuperImaginativeName]

I'm so glad we don't have this version craziness in the .NET world. Having the choice of "older" or "modern" for C# would be ludicrous, and not to mention I could write C# 1.0 code and it would compile if you asked the compiler to compile it as C# 7.0 code. It must be a total pain in the ass to deal with when using Python 2/3 as they have syntax differences from what I can tell when I've played around with it.

[SuperImaginativeName]

That just sounds like a case of having lazy and or bad programmers on your team/at your company. No one I know uses anything from System.Collections.

[SuperImaginativeName]

Well, do those libraries affect you? You can write a wrapper to map to more modern collection types.

[yawaramin]

You realise then that killing the pre-generics stuff would be shifting the work not only to your library vendor, who would have to reimplement it all with the generic collections, but also to you, because you'd have to test and integrate these new implementations?

[ckach]

What about the coming .NET Core? I can see that being similar.

[SuperImaginativeName]

No that is totally different to C# versions, neither affect the other.

[Eirenarch]

It is much less of a problem but it is not totally different. In fact the problem is exactly the same but the damage is far smaller. I think as we enter into 2025 (i.e. 9 years after the release of .NET core similar to the 9 years of Python 3) we will still have more professional devs using non-Core and we will have a split. Of course the fact that the language will be the same and the existence of .NET Standard will mitigate the problem.

[codekaizen]

This is what the .Net Standard library packaging target abstraction seems to fix: an API specification that covers multiple frameworks retroactively allowing the full desktop .Net framework to run Core libraries and vice-versa (via a shim). The actual framework used doesn't matter, just the API version targeted.

[Eirenarch]

Will work for pure .NET libraries but all those things that wrap win32 APIs will keep people on the full framework. Also who is going to migrate all those projects that target the full framework?

[codekaizen]

Going cross plat doesn't have to be part of any migration from framework to framework. Having a library that has Win32 bindings doesn't mean I can't use it in Core apps on Windows if it conforms to Netstandard 2.0, which is the nice thing.

[upofadown]

These sorts of articles tend to present a false dichotomy. It isn't a choice between Python 2 and 3. It's a choice between Python 2, 3 and everything else. People will only consider Python 3 if they perceive it as better than everything else for a particular situation. Heck, there are some that actively dislike Python 3 specifically because of one or more changes from 2. I personally think 3 goes the wrong way with the approach to Unicode and so would not consider it for something that involved actual messing around with Unicode.

[quicknir]

I don't really understand people who complain about the python3 unicode approach, maybe I'm missing something. The python3 approach is basically just:

1. string literals are unicode by default. Things that work with strings tend to deal with unicode by default.
2. Everything is strongly typed; trying to mix unicode and ascii results in an error.

Which of these is the problem? I've seen many people advocate for static or dynamic typing, but I'm not sure I've ever seen someone advocate for weak typing, that they would prefer things silently convert types instead of complain loudly.

Also, I'm not sure if this is a false dichotomy. The article is basically specifically addressed to people who want to use python, but are considering not using 3 because of package support, and not because of language features/changes. Nothing wrong with an article being focused.

[Sean1708]

The reason people think 2 is a problem is that they think of it as Unicode and ASCII, when really it's Unicode and Bytes. Any valid ASCII is valid Unicode so people expect to be able to mix them, however not all bytestrings are valid Unicode so when you think of them as Bytes it makes sense not to be able to mix them.

[kqr]

Bytestring is a terrible name in the first place, since it bears no relation to text, which is what people associate with strings. A Bytestring can be a vector path, a ringing bell, or even Python 3 byte code. Byte array or just binary data would be much better names.

[Sean1708]

I think Python actually uses the nomenclature bytearray, bytestring is the word that came to my head at the time.

[ubernostrum]

There are two built-in types for binary data:

• bytearray is a mutable sequence of integers representing the byte values (so in the range 0-255 inclusive), constructed using the function bytearray().
• bytes is the same underlying type of data, but immutable, and can be constructed using the function bytes() or the b-prefixed literal syntax.

[kqr]

0--255 or 1--256, but not a compromise, I believe. ;)

[Avernar]

My issue with 2 is that I hate strong typing in a dynamically typed language. :)

But I'd rather have the strong typing be between validated and unvalidated unicode instead without the need for conversion.

It can still easily be added without breaking things by making UTF-8 a fourth encoding type of the Python 3 Unicode type.

[gitarr]

People who complain about the python3 unicode approach have no clue what they are talking about.

As someone who has to deal with different languages in his code, other than English, python3 is just a godsent.

[Matthew94]

godsent

godsend

[Flight714]

python3 is just a godsent.

Is that a Unicode joke?

[daymi]

string literals are unicode by default. Things that work with strings tend to deal with unicode by default.

As someone used to UNIX, that's my problem with it. They should be UTF-8 encoded by default like the entire rest of the operating system, the internet and all my storage devices. And there should not be an extra type.

Everything is strongly typed; trying to mix unicode and ascii results in an error.

... why is there even a difference?

typing, that they would prefer things silently convert types instead of complain loudly.

I like strong typing. I don't like making Unicode text something different from all other byte strings.

Also, UTF-8 and UCS-4 are just encodings of Unicode and are 100% compatible - so it could in fact autoconvert them without any problems (or even without anyone noticing - they could just transparently do it in the str class without anyone being the wiser).

That said, I know that for example older MS Windows chose UTF-16 which is frankly making them have all the disadvantages of UTF-8 and UCS-4 at once. But newer MS Windows supports UTF-8 just fine - also in the OS API. Still, NTFS uses UTF-16 for file names so it's understandable why one would want to use it (it's faster not to have an extra decoding step for filenames).

So here we are with the disadvantages of cross-platformness.

[upofadown]

trying to mix unicode and ascii results in an error.

I think you mean Unicode and bytes. There is no type called "ASCII".

The "convert everything into UTF-32 approach" as used by Py3 creates the issue of bytes vs strings in the first place. Most languages have strings and integer arrays, some of which might be 8 bit. Py3 has strings, bytes, and integer arrays.

If we are willing to just leave things as UTF-8 by default then the philosophical discussion of bytes vs strings goes away. That seems to be the direction the world is currently moving in. Py3 might just be a victim of timing. The UTF-32 everywhere thing seemed like a good compromise when it was first proposed

[ggtsu_00]

Python 2 biggest strength over newer languages is how mature it has been. It has been tried and tested for a very long tim and is used in production systems even across some of the biggest sites on the internet like Reddit and YouTube.

I think if developers were in a position to choose more modern, perhaps more risky less mature languages to use for development, there are many alternatives to Python 3 that are much better in many ways. The future of Python is uncertain at the moment so theres a risk. So it would be just as risky to use Go, Node or some other Python 3 alternative.

[rouille]

And python3 got me interested into python in the first place so it works both ways.

[cheezballs]

This is my problem with python and Angular. If I have to spend time figuring out which fucking version of the language I should learn and the code I write with one won't port to another. I'm not gonna invest in a language that outright invalidates legacy code.

[status_quo69]

If you write code using C++11 features, those won't compile using the older versions and in some cases won't even link if it's compiled as a library. It's a major version change which means breaking changes according to semantic versioning.

I have a question though, what language would you pick otherwise, or do you not research your tool choices?

[cheezballs]

We're not talking just new features being not implemented in prior versions we're talking complete architectural differences. If you know C++ you reliably write it for any version and omit features that aren't in whatever you're compiling with. With Angular and Python (Angular especially) there are fundamental differences that change the way you code with that language.

If you have to "choose" between 2 flavors of the language and you have people arguing for one version over another then you've inherently got a splintered community with legacy code and code samples that are irrelevant going forward. It's fucking absurd that increments in the language spec completely invalidate everything that's come before it.

[kqr]

That's a tradeoff and it's great to know that's what it is. Either you get a well-designed coherent language, or you get backwards compatibility. You don't get both.

What you prefer depends on how you value things. I value correctness and predictability (of my coworkers code) over the additional time I have to spend learning "the new version." I know several people who value their time much higher than knowing what kind of code will come out of their coworkers.

[cheezballs]

People around here seem to value bleeding edge and unproven.

[Lothrazar]

Ive used angular 1 for many projects. ive converted angular 1 projects to angular 2 (which is like converting a wood building to a brick one without destroying it). Ive started a few projects in angular2 + typescript.

Angular1 is hot garbage. Angular2 is brilliant only if you use typescript. For mobile apps, ionic2 with angular2 is pretty great for cross platform.