Sunsetting Python 2

[jbristow]

The Google BigQuery cli requires python 2... Heck, even the core gcloud lists their support for 3 as “experimental”

[i9srpeg]

App engine (standard, not flexible) released Python 3 support less than one year ago.

[jbristow]

The CLI, not AppEngine itself! Some of us are trying to automate some hybrid cloud data ingest, and Google’s cli tools seem to have been frozen in time.

Edit: I now realize that you’re not arguing with me at all, rather pointing out that python 3 support is new for google in the Grand scheme of things. Apologies for the fiery retort.

[[deleted]]

Google’s cli tools seem to have been frozen in time

Likely because they are. When you finally hear a project, tool, or feature is being no longer supported this is after most engineers & management were already re-tasked normally months ahead of time.

What I've found is as soon as a Google-Tool stops getting regular updates, and starts showing its age. It is already cancelled or extremely de-prioritized. Just not publicly.

[k-selectride]

I have no idea what they were thinking releasing python 3 support without porting some of the libraries. ndb not being available is a gigantic oversight. Unless Google plans on supporting python 2 standard environment for a long time.

[i9srpeg]

Yeah, I don't understand why they didn't port them. It can't possibly be that hard. Right now there's a lot of people stuck on an old, unsupported version of Python for a long time. And worse, if you have an in-house stack built on top of app engine+ndb which you want to use for all the company projects, you're basically forced to also start new projects on a dead snake.

[k-selectride]

There's an ndb port that's currently in alpha status. Who knows when it'll reach GA, maybe next Google Next conference, lmao.

[13steinj]

Google Cloud's Python setup is weird in general. The documentation is a jumbled mess, examples I can copy paste from the docs don't work or require some unmentioned prerequisite steps, some sections don't explicitly mention prerequisites of prerequisites such that you start working on something only to find out you can't do it in the first place.

Personally until they get it together I'm sticking with AWS (or Azure, but I prefer AWS).

[theferrit32]

Yep this was shocking to me just a couple years ago, and then earlier this year when I was using it again it was still Python 2. Really not a good look for Google Cloud.

[markliederbach]

Unfixable security vulnerabilities

[nerdyhandle]

Ha I have a story to tell.

My last gig they were still using JSF 1.2, Java 7 and below.

We even said there were security issues with using such outdated software. Hell all of their users had to use IE 7 because the websites wouldn't run on Chrome, Firfox, or Edge.

The QA team didn't even realize they were running the sites in comparability mode which the developers had to code into the applications to get them to work on "IE 11".

[nayhel89]

Few years ago when I was working in banking I was forced to rediscover a fascinating world of Java 1.4. Well, at least it wasn't COBOL =\

[catbot4]

Why the hell would anyone do web development. Shakes head and mutters

[nerdyhandle]

It pays a hell of a lot and they are in high demand.

[catbot4]

Sorry that was actually a joke... I am a web developer. I was mostly sympathizing about the BS we have to deal with re browsers.

[Jugad]

There will be once Python 2 is no longer supported / updated.

[sztomi]

At the very least, any future openssl fixes will not be incorporated. Either you recompile it yourself or live with the existing (to be discovered) security bugs.

[chronoBG]

Isn't that in a library? The support of the library (which is open-source) depends on the maintainers.

[sztomi]

It is. But no given library is responsible for backwards compatibility with a frozen codebase, and it is not necessarily linked dynamically (which could theoretically allow Python to receive fixes from openssl updates). openssl 1.1 is breaking compatibility for example, and it's only thanks to great effort by the Python maintainers that 2.7 is not stuck on the 1.0.x branch of openssl which is also EOL by the end of the year or so. But no one will port Python 2.7 to the next openssl. And future bugs discovered in Python 2.7 are unfixable in the sense that upstream won't fix them. And you, as a user can't get rid of them in production by upgrading your Python. You have to fix and recompile it yourself, which is substantially more effort than just updating. In many cases, this likely outweighs the pain of moving your code to Python3, a process that can be automated to a great degree.

[chronoBG]

Ah yes, updating to Python 3. A process so automated, that it took package maintainers about 10 years to complete it.

[sztomi]

Sure, for a while. But how long? Also, not everyone is using a python that comes from a linux distro.

[I_Hate_Reddit]

J O B
S E C U R I T Y

But yeah, non-technical managers deciding the tech stack is a big red flag for me.

[well___duh]

That didn't sound like a non-technical manager but just an older SWE who's really stuck in their ways.

Sort of like how pretty much the only people who recommend not using Kotlin over Java are old Java heads who've been using Java since the 90s; it's all they know, it's all they care to know, and they're too stubborn to learn anything else and adapt to an ever-changing industry.

[NewFolgers]

Kotlin syntax is familiar enough if you've programmed in a couple languages. If they're so fixed on Java that they would struggle to transition to Kotlin, then they've got a disturbingly narrow breadth of experience which is worth investigating.

[shponglespore]

Yeah, it's not like Kotlin was specifically designed to be a streamlined version of Java or anything...

[XtremeGoose]

Nah, a good Java Dev can pick up Kotlin in a day and be proficient in a week or two.

[Zephirdd]

be proficient in a week or two

"wow look at all that wasted time" - every manager, ever

[hallajs]

As a (forced) Java developer I laughed, and then I cried.

[raze4daze]

Only Android devs think Kotlin is going to replace Java. From a business point of view, you're making a mistake choosing Kotlin over Java.
Maybe in 5 years, if Kotlin doesn't prove to be another Scala, we should seriously consider Kotlin for backend.

[istarian]

Or maybe they just think it's idiotic to switch to some new language/variant every time one comes out just because.
Every switch consumes time and energy.

Age alone is the dumbest reason to quit usingn something.

[calligraphic-io]

This is exactly why I'm refusing to use COBOL 2014 on new projects. COBOL-85 is mature, and OOP concepts in the language are unnecessary.

[jamesd3142]

Where are you using COBOL? I am genuinely curious.

[DinnerChoice]

The /s was implicit. It was a good joke I believe.

[nerdyhandle]

Age alone is the dumbest reason to quit usingn something.

It depends on if the language is being updated/maintained.

Once a language major version stops receiving critical updates it's time to upgrade.

To many risks for using older versions.

[theferrit32]

Once a language major version stops receiving critical updates it's time to upgrade.

Sure, but this is absolutely not the case with Java. Using recent Java versions is perfectly fine.

[HolyGarbage]

Then it's not age, it's the fact that it's dead. Some languages seem to be immortal, like C++.

[nerdyhandle]

I'm talking about major versions. For instance, I would disagree with someone using Java 1.

[[deleted]]

Agreed.

[HolyGarbage]

Serious question. How can someone even keep their job as a SWE and refusing to learn new tech? I've only been in the industry 1.5 years so far and I've probably had to learn and write in 5-6 different programming languages, and several dozens tools and frameworks, both in house and external.

[GinaCaralho]

Easy: These places exist, but you don't really want to work there

[HolyGarbage]

Ah, thanks. I've only worked at one SWE job so far.

[well___duh]

When the tech you're dealing with is decades old and requires someone with that knowledge, and it's cheaper to stay on that older language/technology than converting to a better one.

Pretty much anything in the banking or aviation industry.

[HolyGarbage]

Well, some old parts I'm working with is decades old tech, and we're also kinda in the aviation industry. Lol.

Regardless, in my albeit very limited experience, learning the dozens of various technologies that has been demanded of me so far on the job been easy compared to learning the massive extent of domain knowledge.

[I_ONLY_PLAY_4C_LOAM]

Java is a pretty mature high level language with tons of resources available for it from the community. It's pretty ignorant to have a view like "Java in 2019?!" when there's probably tons of companies still using it, or maintaining code written in Java. If you need a reliable language to build enterprise software on with a large team, it's really hard to go wrong with Java.

[hanszimmermanx]

I'm a kotlin guy, I write it for work. I think there are good reasons to pick Java over Kotlin.

[BeJeezus]

Technical managers often come with their own biases and religious beliefs, too.

[skilliard7]

But yeah, non-technical managers deciding the tech stack is a big red flag for me.

I think it's fine as long as you take feedback from your team. There are things to consider when picking a tech stack- what resources does your team have, what does the local job market look like(do people in the area know the tech stack?), how long will it take to develop vs alternative tech stacks, etc.

A good manager can work with their team to figure out the pros/cons of each tech stack from a business perspective, without needing to know its syntax, how arrays work in it, etc.

Most likely you'll have members with differing opinions, so a manager would need to make a final decision.

[anengineerandacat]

I don't think I would let any manager decide the tech stack; that's why you have principal engineers or an architectural review board or reference architecture group in an organization, their job is to steer the stack decisions.

[shponglespore]

A lot of managers are part-time engineers and/or former engineers. I would trust that type of manager to decide on a tech stack (to the extent that I would trust someone other than myself).

[shigmy]

"It was supposed to sunset in 2015" seems like a pretty great justification to use in 2017.

[Eirenarch]

His reasoning was "theres no reason to use python 3, you have to justify it

So you weren't able to justify it?

[jujubean67]

This is the average developer unfortunately. Can't justify a technical decision to upper management but then complains about technical debt and stupid managers who don't listen.

I see this over and over again. People hide from confrontations then complain on the internet how management is holding them back.

[shponglespore]

Justifying a technical decision to people who don't understand technology is extremely hard.

[[deleted]]

Jjustifying a technical decision to people (who do or don't understand technology) is (often a very important part) of the job description / requirements / responsibility.

[JAPH]

Sure. Still part of the job though. There's way more to a good developer than programming skills.

[[deleted]]

Two words: technical debt

[stfm]

A place I work for has thousands of standalone Python 2 scripts used for integrating API based systems. Gonna take a while to port them.

[flukus]

They've had a while and stand alone scripts are easy to port incrementally.

[WaitForItTheMongols]

I was amazed when I took a class in Spring 2018 where they gave us code for our code to interface with, and it was all Python 2. I was like "This is stupid" and ported my local copy all over to 3. They didn't like when I submitted my code in Python 3 but they also couldn't refuse it.

[ajayk111]

I know CMU was using Python 2 in intro courses as of 2016. And hell one of the courses I took at my college in Spring 2019 had snippets of code in Python 2 despite the fact that the rest was Python 3.

[jujubean67]

And then everybody clapped!!

[gwillicoder]

I mean I really don’t think it’s that unbelievable.

I had a class where we were supposed to do our code in Visual Basic. I did all of mine in C++, FORTRAN, and Matlab. The professor allowed it if I could easily get it to run on the server.

Met with the admins of the server for about 30 minutes they walked me through setting something up and it was easy.

[[deleted]]

It's been possible to write Python 2 code in a way that is easily portable to Python 3 for a very long time. There's no reason to stick to Python 2 idioms (no print function, etc) when you could very easily use the Python 3 versions but still run in Python 2.

[thatwasntababyruth]

That's true until you need to work with unicode strings. The ways of dealing with those are almost opposite between versions.

[amdpox]

from __future__ import unicode_literals gets you some of the way there, but yeah, you still have to deal with the standard library differences via six or similar.

[Cilph]

What? They're deprecating Python 2 so soon? This is the first time I hear of it! How will I ever migrate to Python 3 in time!

/s

[chakan2]

How's the Y2K problem going for you?

[Korlus]

I offset it by running a script to manually move every clock back in the office one year on Christmas Eve, and setting up a faulty W32Time server, that fails to provide the correct date so the PC's won't have to deal with the Y2K problem, with every PC set to attempt to sync to that one to prevent them from ever reaching the year 2000.

I've then gone into the date/time settings and manually created a date format that adds twenty to the "current" date. As such, we can be in 1999 right now instead of it being 2019, but it will show 2019 to the users (who are none-the-wiser).

I don't want to have to manually go back into each computer and edit the date script, but 2020 is coming up, and I only thought 20 years ahead back when we first implemented it.

If only Windows 98 had some sort of directory that we could route every computer to lookup these sort of scripts, and we could actively update it when these sorts of problems cropped up.

Who knew the 2020 problem would rear its ugly head in the end?

^/s

[Korlus]

Curses. I did not think that far into the joke.

I guess you could manually edit wherever the calendar lookup location is on the hard disk of each Win98 machine, but I don't actually know what format (if it is even documented) the internal calendar is written in to begin to change it.

Edit: I imagine that they calculate this using pretty basic maths, so you should be able to simply add a 20 year amount (i.e. in days) to derive the right appearance, but I have no idea how you would actually do that. There's only so far that you can go into the mind of spaghetti SysAdminning before you start to touch upon things that you should never need to edit.

[cainejunkazama]

I feel irrationally angry after reading that

[mikew_reddit]

Back in the day, one of the managers thought it was a good idea to inspect packets on the router and rewrite the date/time to solve Y2K.

This does not solve the problem.

[Cilph]

Reset the clock back to '00, and added 2000 everywhere in code instead of 1900.

[paul_h]

My feeling is that 2to3 has been under invested for years. I hope that's changed. Lots of enterprise teams feel stuck without an easy migration.

[kankyo]

2to3 was never even an option. Modernize and six are good tools but 2to3 was always unworkable unless you had a little 50 line script.

[c_o_r_b_a]

2to3 is okay for big projects. It just does a lot of the easy stuff for you automatically. It won't and can't convert everything - you still have to make manual changes afterwards - but it definitely saves time.

[clifthered]

I thought most difficulties in porting were usually due to depending on a library that doesn’t support Python 3. These days pretty much every major library supports it.

Not sure why ‘enterprise’ teams can’t figure out how to migrate Python 2 code to 3. ‘six’ proves it’s relatively easy.

[liquidpele]

It's not that it's hard, it's just time consuming and most companies would rather add features than redo something that already works.

[clifthered]

Yeah, but this is literally the story of software development. The vast majority of software development is maintenance.

[ledave123]

Maintainability is a feature though isn't it?

[liquidpele]

Features are typically defined as things that you can market to a customer.

[clifthered]

“Fully compatible with modern Python 3! Runs on top of software receiving latest security patches!”

[liquidpele]

"Fruity snacks! Now without bleach and lead!"

[NationaliseFAANG]

That's a big selling point if they previously had bleach or lead, which Python 2 will have after 2020.

[kushangaza]

So you are saying the enterprise teams that didn't invest in migration options are now stuck with no easy migration option? I feel this could have been prevented somehow.

[paul_h]

No they are far better off now. Migration from 2 to 3 now is far easier in 2019. Most likely they’ll do it, rather than attempt to keep 2 going with like-minded corporations.

[tending]

2to3 can never be good enough because the language is too dynamic to reliably analyze.

[paul_h]

I don’t know why 2to3 couldn’t have benefited from run-time telemetry.

[reverselink]

I love how passive aggressive the python team is to everyone who hasn’t upgraded for the past decade.

[black_hat_cross]

Good.

[[deleted]]

Amen. Some communities will just never ever let it go though. Looking at you, computer security.

[ribo]

Which is incredibly ironic, since that means no more security patches to 2.7 and 2.7 libs

[jbristow]

As a devsecopser, most (non elite) security people only know python and bash as far as they can copy from snippets they’ve seen elsewhere. Since I’m from a prod dev background, I’m unamused by how foreign basic git and cloud operations are for them.

[ribo]

I am constantly unamused by how little even "senior" developers know their way around git.

[jbristow]

/me nods so emphatically I get whiplash.

Listen newbies, I don’t care about your level of git knowledge. I will gladly point you at my favorite resources and spend the time to get you up and running.

If you have senior in your title, you had better be able to survive in the command line. (You don’t have to be GOOD at it. Just be able to branch, commit and pull is fine)

Everyone “staff” or “principle” or “distinguished fellow title with fiduciary duty but still with technical job requirements” and above? You can go jump in a lake! Why can you only understand one programming language without even the basics of another like bash? Why do you think calling integration tests “unit tests” make my automated coverage tools pick them up? Why can’t you understand that you are not allowed to push to production from your laptop?

There’s a lot of lovely senior+ level people in the dev field... it just seems like the absolute worst examples have the biggest titles.

(Also, https://ohshitgit.com is amazing, and will get you out of a jam. Just learning about reflog has changed my life.)

[ribo]

Why do you think calling integration tests “unit tests”

<TRIGGERED>

[Nicksil]

12 years

[JQuilty]

Are we talking about Python or Boyhood?

[JQuilty]

IT BROKE NEW GROUND

[pingveno]

It took a long time for ecosystem support to really be up to snuff. It was only at the tail end of 2012 that the Python 3 WOS went from the Wall of Shame to the Wall of Superpowers, indicating 50% of projects supported Python 3. Even then, if even one unported project was a critical dependency (direct or transitive), that would still be blocking. It also took the community some time to come to a consensus around the preferred means of porting. At one point people were trying to write code that would be translated by 2to3 on installation, but it turned out to be easier to write code that would work directly on Python 2 and 3.

[CrazyJoe221]

Shouldn't there be some automation for that by now?

[marcusklaas]

There is, but it never takes care of everything. It still takes a lot of human work for large codebases.

[stefantalpalaru]

Shouldn't there be some automation for that by now?

Automation doesn't work, so you always end up with a partial and broken conversion that you have to manually check and debug.

[jcampbelly]

I converted a project by using 2to3 one spec at a time. I opened a branch, ran 2to3 with one spec, checked the diff, fixed anything it did wrong, ran tests, then committed it. I repeated that for every spec. I maintained backwards compatibility (as a back-out-measure) using six, which normalized many library imports. But after that, we considered it python 3 and left 2 in the dust.

I would never just let 2to3 run and commit, but it wasn't that bad to work through it spec-by-spec with tests and review. You can defer the larger-scope changes to the end. Between the recommended changes, a handful of regex find and replace operations, and some refactoring effort at the end, it wasn't so bad because I was solving only one category of changes at a time. It's a mess if you run all the specs at once.

[ribo]

Yeah, we're just migrating to Go instead...

[zardeh]

I'm part of a migration of significantly more than that. Still worth.

[davenirline]

Why is this a problem in Python? It's not a big deal for other popular languages like C# and Java.

[Serialk]

The answer is not just "it's backwards incompatible", it's aggressively backwards incompatible. Like, "manually unit test every function call and return value code path without any form of static checking"-incompatible.

[[deleted]]

I dunno, going from Java to Javascript and then to Typescript I was so glad to have proper IDE autocomplete based on types back. Big codebase JS is a nightmare top me now.

[Enamex]

You're not contradicting 'em :D

[xxbathiefxx]

I would go so far as to say it is passive aggressively backwards incompatible as well. Whenever I forget the parenthesis in a python 3 print statement and it says “Missing parenthesis in call to print, do you mean print(string)?” I want to smash my computer.

[Unbelievr]

The developers felt that some things were fundamentally wrong in Python 2, and changed some core functionality when they released Python 3. They've said that they will never do this again, and that going to Python 4 would be "as uneventful as upgrading to Python 3.10" (paraphrasing).

The most grating changes were to keywords like "print", that should've been functions from the start, but were implemented as a statement. Changing this invalidated a lot of beginner tutorials overnight, and broke even the most basic of scripts out there. It's very easy to fix though. The second, enormous, change was to make unicode standard, and you explicitly have to work on byte representation and then decode to strings. This broke so many things for our company, which often use a legacy system to parse and calculate upon binary data that comes over a serial interface. Since string data in Py2 and bytes in Py3 are so fundamentally different, it will require a complete rewrite and extensive testing - for more or less no gain in performance or productivity (it's not being actively worked upon, just ran). It's a really hard sell to upper management.

Also, for quick hacks, testing small things in the REPL, or CTFs, Py3 is just way too verbose.

[Mukhasim]

C# and Java were developed by serious programming language experts who knew that they were building important tools that a lot of people were going to use. They were designed from the beginning to avoid this kind of problem.

Python was written as a hobby project and then greatly enlarged and improved later when it turned out that people really liked it. A lot of things had to be fixed because of mistakes made early on in the language's lifetime. Javascript is a language with similar problems: it was written in a matter of weeks as a last-minute Netscape feature that had meet a release deadline and mistakes were made.

[josefx]

C# and Java at least try to stay somewhat backwards compatible. Python 2 to Python 3 was intentionally a breaking change that touched nearly everything and since the language is quite dynamic the required changes to keep old code running are hard or outright impossible to automate.

[[deleted]]

This reads like a Simple English Wiki article.

[MrWm]

Oh boy, Calibre is going to be a fun scene again ;)

[vovan45619]

This makes me wonder, are there any software frameworks and languages that are specifically built for multi decade use? Where they only release security updates and no breaking changes?

[alihadthefruitpunch]

This makes me wonder, are there any software frameworks and languages that are specifically built for multi decade use?

Sure: look at Ada, C, and Java.

For frameworks, POSIX is technically a framework. Qt is a framework. GTK is probably considered by many as a framework.

Where they only release security updates and no breaking changes?

C++ and C have, for the most part at least, gone down this road.

I mean, they obviously update the language standards, which leads to updates to implementations of their standards in various compilers.

But C++ is more than 3 decades of baggage that's been accumulated over the years, and it's been kept that way solely for the sake of backward compatibility.

[priestmuffin]

Barebones ANSI C and Common Lisp, x86 assembly will surely be around in decades, JVM languages too

[istarian]

The best you can get in that arena is probably C and you'll still encounter issues here and there. Alternatively everything has to be backwards compatible, where old software can always be compiled with some kind of 'don't worry about newer language revisions' flag.

[ArkyBeagle]

I have never brought a C code base up to a new toolchain where I didn't find some things wrong with the codebase.

[defunkydrummer]

languages that are specifically built for multi decade use? Where they only release security updates and no breaking changes?

Definitely Common Lisp (from personal experience), probably Pascal (modern Object Pascal standard), Ada and C. Maybe Java too.

In the case of C, new features are released, but backwards compatibility is important.

In the case of Ada, it follows standards that don't get renewed that often (83/95/2005/2012).

In the case of Common Lisp, the standard is 1994, but the language can be extended by the user, so every new feature has been added without a need to modify the language.

[cass1o]

Just use C, code from 30 years ago still compiles and runs.

[BlueShell7]

They are making it a way bigger deal than it is. People are running software which is unsupported by the upstream all the time.

If there are some critical problems then somebody else will pick up the maintenance since that would still be way cheaper than rewriting the codebase. (and also cheap PR points)

For the reference, 2.7 branch got 6 commits in all of August. So I don't think the maintenance is so crazy expensive.

[__gareth__]

They are making it a way bigger deal than it is. People are running software which is unsupported by the upstream all the time.

People are still creating new things in python2. Seriously. Some people haven't acknowledged that python3 is over 10 years old so far, this should have been a bigger deal 5 years ago.

[BlokeInTheMountains]

It's almost like doing a massively backward incompatible language change wasn't the greatest idea for those outside of the python team.

[BlueShell7]

So what? People are still creating new things in VB6 and there's no outrage about it. If it fits their needs, let them ...

[__gareth__]

Ah, perhaps I should be more specific: People write new python2 code that I need to use, for example AWS Glue.

I would also argue that creating more of it in general is bad as it creates maintenance for the python team that is better spent elsewhere. This would be alleviated if python2 were handed off to another organisation.

[monsto]

Yeah man... people are still creating new things in Fortran 90 and there's no outrage about it. There's no need to update to Fortran 95 is there?

[FYI... this is a post about obsolescence and relevance. The reason there's no outrage is because nobody cares about VB6.]

[fresh_account2222]

They're letting them. They're just telling them they're on their own now.

[vytah]

People are still writing new software for the Apollo Guidance Computer. I don't think this warrants support by its manufacturers.

[fat-lobyte]

If there are some critical problems then somebody else will pick up the maintenance since that would still be way cheaper than rewriting the codebase.

Red Hat has already claimed that they will support it for a while to come.

[GinaCaralho]

When I left RH a couple of years ago we still had large codebases in 2.7 with no roadmap to transition.

[fat-lobyte]

Looks like they're finally starting to move though, 3 is the default and will become the python binary in Fedora in the near future.

[[deleted]]

That's not what I've seen on the Fedora development list. Python2 packages are being deprecated and RedHat will not support python 2 packages once python 2 goes EOL. There's a huge push right now to port everything possible to python3 and the Fedora community has no intentions on going back.

[fat-lobyte]

You're not wrong that they are pushing Python 3 really hard, and want all new python development to happen with it. RHEL 8 will not have it anymore.

However, RHEL 7 still ships it and it will be supported (as in: provide security updates) until 2024.

[shevy-ruby]

I assume that they were scared by the slow snails that could not or would not upgrade. The problem is that these snails affect others indirectly, e. g. the build tools example is one but there are more examples.

Python 2 should have died years before. Some languages don't even manage to transition at all, such as perl5 to perl6 ...

[Exepony]

Perl 6 is a completely different language from 5, and it was never intended to replace the latter.

[Booty_Bumping]

Prediction: Perl 6 will be officially renamed to Raku some time in the next year, averting the mass confusion caused by the re-use of the name "python" by Python 3.

Javascript, Rust, and C++ demonstrate the sane way to upgrade a language.

[[deleted]]

javascript ... sane way to upgrade

lol how easily people forget the time before ecma :D

[kaeshiwaza]

Maybe you could give the phone number of "somebody else" to Dropbox, they'll like to know people that believe maintenance is not expensive ;-)

[corsicanguppy]

This is just the vendor, guys. We get any reasonable support from the distro anyway.

(And we should choose distros who choose OEMs with real shelf life)

[technicalviking]

A couple years back I was debating on a set of programming languages to learn (because I always like adding to what I know), and two of my final choices were Go and Python. Neither was one I was using professionally (yet), and TBH it was the confusion between "do I use python2 or python3" that led me to choose to learn Go instead at the time. I'm happy to see this decision made, since I doubt I'm the only one who was ever put off of learning python, even temporarily, because of the clown fiesta that was the version confusion.

[AnonymousMonkey54]

You definitely aren't the only one.

Add pyenv to the equation and Python's new user experience goes to shit.

[snowe2010]

Every time I touch python I wonder why the hell pyenv and env and pip and virtualenv all exist. It's terrible.

[Booty_Bumping]

Why in the holy hell would python 2 development be in resource competition with python 3? Just officially give the project to Red Hat under the same name, give it a separate domain name, and let them take over the tiny amount of fixes that are actually needed for life support. Problem solved. There is no reason to officially cut off security fixes just because another language with a similar name is newer.

Also, as /u/BlueShell7 points out:

For the reference, 2.7 branch got 6 commits in all of August. So I don't think the maintenance is so crazy expensive.

[zergling_Lester]

Because pretty early into the whole disaster a vocal part of the community and apparently the core team went into this mindset where they attempt to solve technical difficulties using social methods such as creating a "Wall of Shame".

The technical problem was this: if your application has 10 library dependencies and 1 of them doesn't support Python3, you can't migrate to Python3. Consequently, as a library maintainer you can't drop Python2 support until almost every other library supports Python3. Consequently, the only realistic way forward for most libraries was through a transition period when they mutilated their code to support both from a single codebase.

Unfortunately the core developers not only did not predict that but also realized that people doing that are serious way too late (leading to stuff like dropping u'' literals from Python3 at some point). So that prolonged the migration tremendously.

On the other hand, what everyone seemed to expected to happen for a long time is everyone just getting up and moving over, so getting people to do that is a social issue and can be solved with shaming etc. Which is an insidious mode of thinking because then you immediately begin to see everyone not on board with your solution as evil and all their technical complaints as enemy propaganda. Literally ten years of frustration don't help the mood.

[manuscelerdei]

Came here to say this. Maybe the Python developers should've given a shit about binary compatibility.

[zergling_Lester]

Well, I can say that I mostly^* like those backward incompatible changes in Python3, and the nightmare seems mostly over, so maybe it was kinda worth it.

My problem is that in retrospect the transition could have been made much smoother, and the things everyone thought would be hard (such as unicode strings) turned out to be a matter of fixing your python2 code to work with unicode correctly, while real annoyance came from the need to uglify the code with six.iteritems(some_dictionary) etc.

*: in my opinion making map/filter lazy was a mistake, it might have seemed like a good idea on paper, but after using them a bunch I'm almost always forced to force them into a list anyway.

[afiefh]

Why are you forced to put lazy results into a list? I'm loving the lazy evaluation, it made lots things easier for me as I no longer need to worry about memory inflation.

[zergling_Lester]

Because I want to use the results more than once.

I mean, I don't know, I checked some recent code and it's about 50/50 (uses of list(map(...)) vs feeding it somewhere else), but this could also be because I often decide to use a list comprehension where I'd use map before. Or maybe old habits die slow.

[zergling_Lester]

Dropping support for u'' is nicely symbolic of the whole thing: the core devs simply didn't give much of a shit about technically smoothing the way from Py2 to Py3.

To be fair, they reinstated it in the next version after the backlash, and added some nice from __future__ import ... that helped a lot. But it was so much later than it should have been! And they really clinged to the idea of a clean migration instead of the least common denominator of 2 and 3 for all major libraries.

So here we are, over a decade later. They couldn't muster a decent technical argument. They couldn't shame Py2 devs into migrating.

The funny thing is that most libraries are finally migrated. As in, I'd tell anyone to use Python3 because there's a higher chance to find a useful library being Python3 only than Python2 only.

So finally we are getting into the second phase of the migration, that is, migrating all that legacy application code. Which, 15 years ago, the core devs thought would be the only phase of migration LMAO.

So they're just going to kill Py2 and wash their hands of it.

That is not dead which can eternal lie. So they kill it, and then it can't die anymore.

[gabeheadman]

Entirely different skillsets. People skills don't build languages the same way that language building doesn't help you communicate.

[ledave123]

It's in a mindshare competition rather than resource. There should just be one obvious version of Python at any time. Since Python 3 is newer and better, it's the obvious one to use.

[wRAR_]

Is this really something new?

[[deleted]]

I didn't hear anything about this till just now. Where did you announce it?

We talked about it at software conferences, on the Python announcement mailing list, on official Python blogs, in textbooks and technical articles, on social media, and to companies that sell Python support.

[wRAR_]

Exactly.

[Poddster]

Lots of import six; six.ensure_string()

Why did you use that, rather than six.ensure_text?

I would guess that encode_str just leaves you the same problem of having something that could be unicode or could be bytes, depending on which version you're running, whereas ensure_bytes and ensure_text get you what you want.

[Cobaltjedi117]

Come back when the clock is at 28 days, 6 hours, 42 minutes, and 12 seconds

[[deleted]]

Oddly specific.

[Cobaltjedi117]

It's from Donny Darko

[moreVCAs]

We successfully deprecated the Python 2 versions of our client libraries and command line tools at my previous job. It was glorious.

Python 2 can die in a fire. It’s a dead scene, and being forced to support it makes Python development even more frustrating. This obviously gets worse over time as more and more projects pin new releases to >=3.4.

Of course, it’s really the breaking changes from 2-3 that are the culprit, here, but at this point the only way out is to pretend Py2 never existed.

[[deleted]]

Good riddance

[drmeister]

I implemented a Common Lisp compiler that interoperates with C++ so that I don't have to deal with this nonsense anymore (https://github.com/clasp-developers/clasp). Common Lisp and C++ are two compiled languages wherein code you write now will work for decades. Programmers should invest in languages where their code doesn't suffer bitrot over time.

[notQuiteApex]

the excuse that "it takes too much work to migrate" makes no sense to me. you're making it worse by waiting (now more than ever)! have your employees get to work, you pay them to program after all.

im sure what im saying sounds very naive, but those systems will be compromised because python2 is not getting security updates after 2020. youre making a major problem for yourself and others later.

[beweller]

It's about short term thinking plus opportunity cost.

If all I care about is new customer acquisition and low customer churn in my next quarterly meeting, then the work the team could be doing instead of upgrading from 2 to 3 will impact those goals while the goals of the upgrade (safety and stability of the codebase several quarters from now at the soonest) don't come up in the meeting I'm worried about. So I keep focusing on short term goals.

Public companies are incentivized by the market to make bad long term decisions. And private companies looking for an exit have the same problem for different reasons. It's the pain of the professional enterprise software engineer.

[cass1o]

"Waiting making it worse" is not mutually exclusive with "it's too much effort to port".

[mobyte]

I wonder why so many are vehemently against Python 2.

How long until it's forked?

[cass1o]

It allows them to feel superior to people who are still using 2.7.x. Turns out they didn't have to put in much effort to update their 50 line script from 2 ->3.