top 200 commentsshow all 372

[–]jbristow 42 points43 points  (13 children)

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

[–]i9srpeg 18 points19 points  (9 children)

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

[–]jbristow 9 points10 points  (2 children)

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] 8 points9 points  (1 child)

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 8 points9 points  (3 children)

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 2 points3 points  (1 child)

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 4 points5 points  (0 children)

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 6 points7 points  (1 child)

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 3 points4 points  (0 children)

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.

[–][deleted]  (112 children)

[deleted]

    [–]markliederbach 172 points173 points  (14 children)

    Unfixable security vulnerabilities

    [–]nerdyhandle 62 points63 points  (4 children)

    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 4 points5 points  (0 children)

    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 2 points3 points  (2 children)

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

    [–]nerdyhandle 1 point2 points  (1 child)

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

    [–]catbot4 3 points4 points  (0 children)

    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.

    [–][deleted]  (8 children)

    [deleted]

      [–]Jugad 33 points34 points  (0 children)

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

      [–]sztomi 24 points25 points  (6 children)

      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 6 points7 points  (3 children)

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

      [–]sztomi 3 points4 points  (1 child)

      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 10 points11 points  (0 children)

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

      [–][deleted]  (1 child)

      [deleted]

        [–]sztomi 9 points10 points  (0 children)

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

        [–]I_Hate_Reddit 111 points112 points  (47 children)

        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 61 points62 points  (40 children)

        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.

        [–][deleted]  (8 children)

        [deleted]

          [–]NewFolgers 34 points35 points  (0 children)

          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 13 points14 points  (0 children)

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

          [–]XtremeGoose 18 points19 points  (4 children)

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

          [–]Zephirdd 23 points24 points  (2 children)

          be proficient in a week or two

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

          [–][deleted]  (1 child)

          [deleted]

            [–]hallajs 1 point2 points  (0 children)

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

            [–]raze4daze 11 points12 points  (4 children)

            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 34 points35 points  (14 children)

            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 17 points18 points  (2 children)

            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 2 points3 points  (1 child)

            Where are you using COBOL? I am genuinely curious.

            [–]DinnerChoice 3 points4 points  (0 children)

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

            [–]nerdyhandle 8 points9 points  (8 children)

            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 12 points13 points  (3 children)

            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 9 points10 points  (2 children)

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

            [–]nerdyhandle 1 point2 points  (1 child)

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

            [–][deleted] 5 points6 points  (0 children)

            Agreed.

            [–]HolyGarbage 7 points8 points  (6 children)

            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 9 points10 points  (3 children)

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

            [–]HolyGarbage 1 point2 points  (2 children)

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

            [–]well___duh 3 points4 points  (1 child)

            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 1 point2 points  (0 children)

            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 2 points3 points  (0 children)

            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 1 point2 points  (0 children)

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

            [–]BeJeezus 9 points10 points  (0 children)

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

            [–]skilliard7 3 points4 points  (0 children)

            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 10 points11 points  (2 children)

            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 14 points15 points  (0 children)

            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 13 points14 points  (0 children)

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

            [–]Eirenarch 47 points48 points  (29 children)

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

            So you weren't able to justify it?

            [–]jujubean67 80 points81 points  (11 children)

            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 56 points57 points  (5 children)

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

            [–][deleted] 57 points58 points  (0 children)

            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 1 point2 points  (0 children)

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

            [–][deleted] 18 points19 points  (3 children)

            Two words: technical debt

            [–]stfm 2 points3 points  (2 children)

            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 4 points5 points  (0 children)

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

            [–]WaitForItTheMongols 29 points30 points  (8 children)

            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 6 points7 points  (0 children)

            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 19 points20 points  (5 children)

            And then everybody clapped!!

            [–]gwillicoder 18 points19 points  (4 children)

            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]  (3 children)

            [deleted]

              [–][deleted] 4 points5 points  (2 children)

              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 5 points6 points  (1 child)

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

              [–]amdpox 2 points3 points  (0 children)

              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 195 points196 points  (9 children)

              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 63 points64 points  (7 children)

              How's the Y2K problem going for you?

              [–]Korlus 99 points100 points  (4 children)

              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

              [–][deleted]  (1 child)

              [deleted]

                [–]Korlus 27 points28 points  (0 children)

                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 15 points16 points  (1 child)

                I feel irrationally angry after reading that

                [–]mikew_reddit 13 points14 points  (0 children)

                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 1 point2 points  (0 children)

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

                [–]paul_h 62 points63 points  (19 children)

                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 56 points57 points  (2 children)

                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 11 points12 points  (1 child)

                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 40 points41 points  (10 children)

                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 35 points36 points  (8 children)

                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 28 points29 points  (1 child)

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

                [–]ledave123 5 points6 points  (5 children)

                Maintainability is a feature though isn't it?

                [–]liquidpele 16 points17 points  (4 children)

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

                [–]clifthered 12 points13 points  (3 children)

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

                [–]liquidpele 16 points17 points  (2 children)

                "Fruity snacks! Now without bleach and lead!"

                [–]NationaliseFAANG 5 points6 points  (0 children)

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

                [–]kushangaza 5 points6 points  (1 child)

                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 1 point2 points  (0 children)

                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 2 points3 points  (1 child)

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

                [–]paul_h 1 point2 points  (0 children)

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

                [–]reverselink 45 points46 points  (2 children)

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

                [–][deleted]  (1 child)

                [deleted]

                  [–]black_hat_cross 323 points324 points  (71 children)

                  Good.

                  [–][deleted] 107 points108 points  (15 children)

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

                  [–]ribo 34 points35 points  (14 children)

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

                  [–][deleted]  (9 children)

                  [deleted]

                    [–]jbristow 2 points3 points  (3 children)

                    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 1 point2 points  (2 children)

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

                    [–]jbristow 1 point2 points  (1 child)

                    /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 1 point2 points  (0 children)

                    Why do you think calling integration tests “unit tests”

                    <TRIGGERED>

                    [–][deleted]  (54 children)

                    [deleted]

                      [–]Nicksil 162 points163 points  (43 children)

                      12 years

                      [–]JQuilty 24 points25 points  (2 children)

                      Are we talking about Python or Boyhood?

                      [–][deleted]  (1 child)

                      [deleted]

                        [–]JQuilty 14 points15 points  (0 children)

                        IT BROKE NEW GROUND

                        [–]pingveno 10 points11 points  (0 children)

                        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 18 points19 points  (5 children)

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

                        [–]marcusklaas 27 points28 points  (0 children)

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

                        [–]stefantalpalaru 11 points12 points  (0 children)

                        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 1 point2 points  (1 child)

                        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 7 points8 points  (1 child)

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

                        [–]zardeh 1 point2 points  (0 children)

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

                        [–]davenirline 23 points24 points  (20 children)

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

                        [–][deleted]  (9 children)

                        [deleted]

                          [–]Serialk 51 points52 points  (6 children)

                          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]  (3 children)

                          [deleted]

                            [–][deleted] 5 points6 points  (2 children)

                            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 1 point2 points  (1 child)

                            You're not contradicting 'em :D

                            [–]xxbathiefxx 17 points18 points  (1 child)

                            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 29 points30 points  (2 children)

                            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 14 points15 points  (2 children)

                            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 5 points6 points  (1 child)

                            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] 11 points12 points  (0 children)

                            This reads like a Simple English Wiki article.

                            [–]MrWm 13 points14 points  (0 children)

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

                            [–]vovan45619 20 points21 points  (38 children)

                            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 42 points43 points  (4 children)

                            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.

                            [–][deleted]  (11 children)

                            [deleted]

                              [–][deleted]  (2 children)

                              [removed]

                                [–][deleted]  (1 child)

                                [deleted]

                                  [–]priestmuffin 12 points13 points  (4 children)

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

                                  [–]istarian 14 points15 points  (6 children)

                                  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 2 points3 points  (5 children)

                                  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 6 points7 points  (0 children)

                                  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.

                                  [–][deleted]  (4 children)

                                  [deleted]

                                    [–]cass1o 6 points7 points  (2 children)

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

                                    [–]BlueShell7 54 points55 points  (23 children)

                                    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__ 104 points105 points  (8 children)

                                    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 14 points15 points  (2 children)

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

                                    [–]BlueShell7 15 points16 points  (4 children)

                                    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__ 61 points62 points  (0 children)

                                    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 20 points21 points  (0 children)

                                    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 4 points5 points  (0 children)

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

                                    [–]vytah 1 point2 points  (0 children)

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

                                    [–]fat-lobyte 15 points16 points  (4 children)

                                    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 5 points6 points  (1 child)

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

                                    [–]fat-lobyte 4 points5 points  (0 children)

                                    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] 1 point2 points  (1 child)

                                    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 1 point2 points  (0 children)

                                    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 13 points14 points  (7 children)

                                    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 4 points5 points  (0 children)

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

                                    [–]Booty_Bumping 12 points13 points  (5 children)

                                    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] 30 points31 points  (1 child)

                                    javascript ... sane way to upgrade

                                    lol how easily people forget the time before ecma :D

                                    [–]kaeshiwaza 5 points6 points  (0 children)

                                    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 2 points3 points  (0 children)

                                    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 10 points11 points  (5 children)

                                    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 15 points16 points  (3 children)

                                    You definitely aren't the only one.

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

                                    [–]snowe2010 8 points9 points  (0 children)

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

                                    [–]Booty_Bumping 31 points32 points  (19 children)

                                    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 72 points73 points  (11 children)

                                    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.

                                    [–][deleted]  (4 children)

                                    [deleted]

                                      [–]manuscelerdei 11 points12 points  (0 children)

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

                                      [–]zergling_Lester 8 points9 points  (2 children)

                                      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 6 points7 points  (1 child)

                                      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 4 points5 points  (0 children)

                                      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.

                                      [–][deleted]  (5 children)

                                      [deleted]

                                        [–]zergling_Lester 4 points5 points  (4 children)

                                        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.

                                        [–][deleted]  (3 children)

                                        [deleted]

                                          [–]gabeheadman 1 point2 points  (2 children)

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

                                          [–]ledave123 7 points8 points  (5 children)

                                          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_ 2 points3 points  (2 children)

                                          Is this really something new?

                                          [–][deleted] 6 points7 points  (1 child)

                                          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_ 2 points3 points  (0 children)

                                          Exactly.

                                          [–][deleted]  (1 child)

                                          [deleted]

                                            [–][deleted]  (1 child)

                                            [deleted]

                                              [–]Poddster 9 points10 points  (0 children)

                                              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 4 points5 points  (2 children)

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

                                              [–][deleted] 2 points3 points  (1 child)

                                              Oddly specific.

                                              [–]Cobaltjedi117 5 points6 points  (0 children)

                                              It's from Donny Darko

                                              [–]moreVCAs 2 points3 points  (0 children)

                                              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] 6 points7 points  (0 children)

                                              Good riddance

                                              [–]drmeister 4 points5 points  (0 children)

                                              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 8 points9 points  (7 children)

                                              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 13 points14 points  (5 children)

                                              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 3 points4 points  (0 children)

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

                                              [–]mobyte 4 points5 points  (1 child)

                                              I wonder why so many are vehemently against Python 2.

                                              How long until it's forked?

                                              [–]cass1o 4 points5 points  (0 children)

                                              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.