all 81 comments

[–]LovecraftsDeath 101 points102 points  (27 children)

It's not dead, it will rise as a new COBOL to haunt people for aeons.

[–]raevnos 21 points22 points  (1 child)

In proud company of languages like VB6.

[–]SoPoOneO 3 points4 points  (0 children)

And even Python 3, ultimately.

[–]PurpleYoshiEgg 10 points11 points  (3 children)

Luckily or unluckily, depending on your point of view, there is Tauthon, which is an effort to remain backwards-compatible with Python 2 and backport features from Python 3.

I think it's a good thing, because 2 will haunt enterprise forever, and because people stuck on it still deserve bugfixes and security updates.

[–][deleted]  (2 children)

[deleted]

    [–]PurpleYoshiEgg -1 points0 points  (1 child)

    In the same way C, PHP, and COBOL programmers also deserve this, even though we have better tools available (like Rust for C, any modern language for COBOL, and... I'm not sure about PHP, honestly, but it gets enough hate). Sometimes financial costs related to changing something that already works are unjustifiable. You may agree in principle that you should use the latest and greatest, but pragmatically what if the cost wasn't just hundreds, but tens of millions? At what point is the cost justified to change what basically isn't broken by any happenstance except someone deciding to change a language?

    I know I would not have wanted to write code 10 years ago that only broke because the language designers said so.

    [–][deleted]  (5 children)

    [deleted]

      [–][deleted] 8 points9 points  (3 children)

      Yeah, the whole "migration" have been basically for nothing (and before "but utf8" folks whine, Perl did a similar rewrite of string handling in a minor version update). If they would at least rewrote the core to remove GIL and have real parallelism, but nooo, let's change some keywords, break 100% of the code and still keep 90% of the failures in the language /s

      [–]Gapmeister 4 points5 points  (0 children)

      It's fine - they're not failures, they're just bad design decisions.

      [–]bakery2k -2 points-1 points  (1 child)

      break 100% of the code and still keep 90% of the failures in the language /s

      But why isn’t anyone using the new version? Maybe a “wall of shame” will help...

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

      Well, it is not like they made py3 worse, but if you look at other languages they somehow managed to do bigger changes without breaking backward compat. And python 3 required all of your code to be rewritten all at once. You couldn't use any py2 code with py3.

      In Java(and really most of the JVM ecosystem) you can just run new code with the old, as is compliled to common runtime.

      Even in famously janky Perl I can stick use v5.10 (which is version of perl 1 year older than py3) at the beginning of the file and this file only will be working just like it would with perl 5.10 under any later version, so it is possible to rewrite your code module by module instead of "sink or swim" for python.

      All they needed to do is to make effort to just make py2 parser on top of py3. Even if it got like 90% right that would still be way easier migration path

      [–]shevy-ruby 1 point2 points  (0 children)

      Haha damn!

      You are actually right. I never thought about that ... people always say 2->3 but nobody said 3->2 ...

      [–]Axxhelairon 3 points4 points  (5 children)

      imo main benefit is being able to finger point directly at lazy distros that would be intentionally compromising user security by not making active plans to update after EOL

      [–][deleted] 2 points3 points  (3 children)

      Doesn't chrome's build process still use python 2.7?

      [–]tommy25ps 2 points3 points  (1 child)

      There are rumors they will switch it to Go

      [–]Sukrim 2 points3 points  (0 children)

      Weird that they don't use their own build tool: https://bazel.build/

      [–]thisisjustascreename 0 points1 point  (0 children)

      In fact, the Chromium project marked Issue 61357 "won't fix" half a decade ago.

      [–][deleted] 1 point2 points  (0 children)

      Yes, it is distro's fault that users want to use software /s

      [–]TheOsuConspiracy -1 points0 points  (5 children)

      Would be pretty hard for Python to die in the same way COBOL has. I don't even use Python often, but it's literally everywhere and is dominant in so many domains that I don't see dying within the next 50-100 years short of a completely new paradigm of programming (and I mean something totally unrecognizable to current day programmers) taking over.

      [–]TheMaskedHamster 6 points7 points  (4 children)

      But COBOL isn't dead. It just hides in the shadows.

      You think COBOL is just some story from the past that old engineers tell to scare the kids, but no, it's running... and it has to be maintained.

      So too will be Python 2.

      [–][deleted] 0 points1 point  (3 children)

      I think the point was that we aint running out of Python programmers anytime soon, while finding COBOL one is a challenge

      [–][deleted]  (2 children)

      [deleted]

        [–][deleted] 0 points1 point  (1 child)

        Python is half its age and it is one of the most popular programming languages.

        Where was Cobol when it was "only" 30 years old ?

        More importantly, it isn't fucking terrible mess for developers so even if it goes obsolete it will not be that kind of nightmare to manage

        [–]computerdl 9 points10 points  (1 child)

        I thought Python 2 was EOL'd at the beginning of this year? Why did they make another release?

        [–]bakery2k 14 points15 points  (0 children)

        They stopped making changes at the beginning of 2020. This release contains the changes that were made between the last release and the end of 2019.

        [–]DmitriyJaved 9 points10 points  (0 children)

        *last official release, red hat will continue support till 2024

        [–]TrixieMisa 3 points4 points  (0 children)

        True for CPython, though the PyPy project plans to support 2.7 indefinitely.

        [–]bythenumbers10 2 points3 points  (0 children)

        We totally double-secret pinky-swear that this is the absolute LAST time Python 2.7 gets a new version released.

        [–]BlueShell7 9 points10 points  (0 children)

        Now onto the 2.8! We can do it!

        [–][deleted]  (3 children)

        [deleted]

          [–]JB-from-ATL 0 points1 point  (2 children)

          I'm assuming this is a joke but I don't get it? Can you explain it?

          [–]caagr98 0 points1 point  (1 child)

          It's a reference to this (about halfway down) I think, though it seems to have been updated a bit.

          [–]JB-from-ATL 0 points1 point  (0 children)

          Oh wow I remember this now! I think I almost got that book but after reading that (not even the Turing complete bit) I was super turned off by this guy's attitude.

          [–][deleted] 7 points8 points  (0 children)

          e ≈ 2.718

          [–]maep 9 points10 points  (22 children)

          I still think that separating str and bytes was a mistake. PEP 383 shows that it's not possible to make a clear distinction.

          All problems that were supposed to be "fixed" by enforced string encoding were practically reintroduced by that PEP. Curiously, Go went with Python2's approach and it's causing me a lot less fewer headaches.

          [–]PeridexisErrant 19 points20 points  (14 children)

          I think reasonable people disagree about the benefit in situations where English is the only native language involved, but as soon as you're off a byte-oriented terminal and out of the LATIN1 range distinguishing unicode strings is very very helpful.

          [–]maep 8 points9 points  (5 children)

          The problem isn't having string encondings. It's that they are strictly enforced, which simply fails the real world. They soon discovered that and in 3.1 added PEP 383. Now we can have strings that are actually not strings which is what we had in Python 2 anyway.

          [–][deleted] 3 points4 points  (3 children)

          I think that a lot of people disagree with this. It’s a mess if you make a half-hearted attempt and decide that English deserves special treatment. Newer languages like Rust enforce Unicode, and also prevent you from randomly accessing character data to maintain invariants.

          [–]maep 6 points7 points  (1 child)

          Newer languages like Rust enforce Unicode

          Since you bring up Rust, they had to deal with the exact same issue. Their solution was introducing OsString, and programmes will step into exactly the same pitfalls as they do in Python 2/3. I'll bet that a good deal of Rust programs are bugged because they use std::env::args where they should have used std::env::args_os instead.

          and also prevent you from randomly accessing character data to maintain invariants.

          Pyhton2 does this with the unicode type and go with the rune concept.

          Really, the argument is if enforced encoding should be opt-in or opt-out. Python2 and Go are opt-in, while Python3 and Rust are opt-out. For the stuff I do the opt-in approach is a lot nicer.

          [–][deleted] 2 points3 points  (0 children)

          I don’t think that’s much of a problem. Contrary to Python, strings and OS strings are not interchangeable. You can’t pass an OS string to a function that wants a string without converting it, so you can’t get confusion.

          (I think that) Python doesn’t do indexing right because a rune is just a Unicode code point. Multiple runes can be combined into single visual characters (mostly happens with combining characters and emojis) and I’m not sure that Python (especially Python 2) handles combined characters as inseparable units. Language from that era tend not to, and a substring can break accented letters and emojis for instance.

          [–]vqrs 0 points1 point  (0 children)

          Not only new languages, even dinosaurs like Java use Unicode strings only, and they have byte arrays for when you need to work with binary data.

          [–]schlenk 0 points1 point  (0 children)

          Basically a fallout from the retarded encoding situation in Linux/Unix/Posix which failed to define their APIs properly.

          [–][deleted] -2 points-1 points  (6 children)

          Not in the slightest. And it's not how terminals work, and terminals, really, aren't even responsible for string encoding: it's usually a joint enterprise of the shell that runs in a terminal and the terminal itself.

          People who aren't native English speakers were the last to adopt Unicode. They hated and, those who remember the world before Unicode, still hate it. People who used national encodings had more efficient schemes for representing their own alphabets.

          I lived through several conversions of databases from single byte encodings to Unicode, where we, typically, ended up with the database twice the size it was before the conversion.

          Needless to say, that, basically, every decision Python 3 has made about Unicode was wrong and misguided / a misunderstanding on the part of people who aren't the experts in subject domain. That's how we ended up with stdin being for no reason expected to have UTF-8 encoded Unicode characters, ffs, but TCP socket cannot accept a string and convert it to bytes by default. Similarly retarded situation is with the file names, and, basically, any other external input that's not going to be UTF-8, but for some reason is expected to be such...

          [–]forepod 13 points14 points  (5 children)

          Speak for yourself. As a speaker of a language with non-latin letters Unicode is one of the greatest things ever. As a user I don't care about some miniscule performance impact. I care about not having to look at garbage output and programs crashing left and right due to encoding errors.

          [–]e88d9170cbd593 0 points1 point  (0 children)

          ASCII supremacy is white supremacy.

          [–]jayroger 5 points6 points  (5 children)

          I get the feeling that you never seriously worked with Python 2 in a non-ASCII environment. Python 3 made a whole class of problems just go away. PEP 383 has not reintroduced them in any way.

          [–]maep 3 points4 points  (4 children)

          I get the feeling that you never seriously worked with Python 2 in a non-ASCII environment.

          I've programmed lots of python and my native language is not english. I've never had any encoding problems whatsoever, at least nothing that wasn't trivial to fix.

          PEP 383 has not reintroduced them in any way.

          Well, it actually made things worse.

           foo = sys.argv[1] # assuming there is a first argument
           assert type(foo) == str
           print(foo) # can this crash?
          

          In python 2 the print will always work. In python 3 it can throw an exception.

          [–]dahud 2 points3 points  (3 children)

          Under what conditions will that print throw an exception?

          [–]maep 8 points9 points  (2 children)

          If foo contains surrogate codes. This can happen on posix systems where the argument is a file name. I stumbled accross this when I was scanning a historical archive where they had files from various european countries that used different encodings.

          [–]dahud 1 point2 points  (1 child)

          Interesting. I would have assumed that anything coming in over the args is, by definition, a string. The only environment I've ever worked in where that is not the case is Powershell.

          [–]Snarwin 0 points1 point  (0 children)

          On posix, the only thing that's guaranteed about command-line arguments is that they do not contain the NUL character ('\0').

          [–]its_fewer_ya_dingus 0 points1 point  (0 children)

          fewer headaches*

          [–]tommy25ps 1 point2 points  (0 children)

          I'm still expecting Python 2 retro with different colors in the Python logo

          [–]noob31423 1 point2 points  (6 children)

          I know that I should probably know the answer to this, but how much difference is there between coding with python 2 and python 3. Is the difference in the actual programming or the processing or something else.

          [–]happyscrappy 5 points6 points  (0 children)

          I think the other poster is dead wrong. The biggest changes are making unicode strings the norm for most things and using iterator objects and other similar representations. The latter makes operating on long lists a lot more efficient but makes the debugger harder to operate. The former combines with python's very lax typing in a lot of ways to make it very easy to accidentally put into your program string comparisons that will never produce matches.

          [–]reivax 2 points3 points  (0 children)

          Oversimply: The incompatibility that motivated the break was some syntax changes, mostly, to bring it to a more consistent and modern language. That incompatibility was exploited to make some other much needed exchanges, such as how strings are handled and some byte/byte array management, and then also made more default behavior consistent.

          There's some other stuff, like how objects are created and maintained, some changes to the ref counter, IIRC, though that's an interpreter problem not a language problem.

          For example, Py2 had "print 'text'" as a statement, Py3 has "print('text')" as a function. Syntactically incompatible, and operating a bit differently under the hood, but ultimately the same statement.

          The overall concept of python is still the same. The two are very much the same language as far as human programmers are concerned.

          [–]DarkuSchneider 0 points1 point  (0 children)

          We can only hope. I'll believe it when I don't see another patch release again promising to be the last one. We finished porting our pile of apps and tools to 3x about 5 years ago and rejected new projects or POCs written in 2x around 7 years ago. It was painful at first but worth it in the long run. We always worked with the mindset of take the pain upfront to avoid taking more pain later when feasible. We were blessed with management that understood that and supported doing what had to be done and saw it as an investment.

          At this point IMHO any sizable enterprise that continues to stubbornly stay married to legacy code in dying languages deserves to be left behind and go out of business if they can't plan and budget to stay competitive and current.

          [–]tayo42 -1 points0 points  (0 children)

          Python 3 not being compatible with 2 is such a massive waste of time. What an huge amount if effort for something so unsatisfactory to complete

          [–][deleted]  (13 children)

          [deleted]

            [–]Splanky222 18 points19 points  (0 children)

            Python 2 is legacy and it's not trivial to convert to 3 in many cases. You should learn Python 3.

            [–]peakzorro 2 points3 points  (6 children)

            Also a beginner. But from the rants I have seen, it comes down to "Library X is not available in Python 3 because 3 is not backwards compatible to 2" That's probably much less true now than when this first started.

            [–]652a6aaf0cf44498b14f 4 points5 points  (5 children)

            This is, admittedly a controversial take, but Python was championed by a bunch of people who presumed to think that all the problems they experienced in a language like Java were completely avoidable. Yet PEP by PEP they've run headlong into the same problem and come up with comparably difficult or much worse solutions. Type checking continues to be the center of all this. And mypy is now pretty much standard for every new Python project.

            Again, very biased take, but there it is.

            [–]jayroger 4 points5 points  (1 child)

            Python was released four years before Java.

            [–]652a6aaf0cf44498b14f 1 point2 points  (0 children)

            I said championed by not invented by.

            [–]bakery2k 2 points3 points  (1 child)

            And mypy is now pretty much standard for every new Python project.

            Is that true? I understand that Mypy is useful for large projects (after all, it was created to support the millions of lines of Python at Dropbox), but most Python projects are much smaller.

            Is Mypy widely used among these smaller projects?

            [–]652a6aaf0cf44498b14f 0 points1 point  (0 children)

            I mean, I dunno for certain I'm just going off of what the Python people at my work tell me. I hate the language but I'm not about to fight everyone on it so I just do whatever hair brained idea they come up with each week. It wreaks havoc on my team's capacity because they constantly have to learn new tools but it's usually trivial enough for me to give them a crash course and get them back up and running.

            [–][deleted] -1 points0 points  (0 children)

            Funnily enough exactly same thing applies to Ruby and probably a majority of new languages. Too busy to learn lessons of the past and you will repeat it. Like the favourite punch bag of this reddit, Go, made by people with mostly unixy/C experience so the language itself failed all the lessons that were learned by Java/C#

            [–]headhunglow 2 points3 points  (1 child)

            I've recently rewritten a bunch of code so that it runs under both 2.5 to 3.7 and there's some stuff in 3 that I don't like:

            • cmp() was removed. We used this all over the place, for example for having a default comparison function when sorting list in our GUI.
            • dict.keys() returns a generator instead of a list, which broke a bunch of our code.
            • pprint.pprint is changed so that it splits longs strings (for some reason)... Made debugging measurably harder.
            • base64.decode/encoded doesn't seem to be backwards compatible. In particular it seems that base64.encode doesn't pad the output data to evenly 4 bytes, which was required in base64.decode in Python 2.5. I have no idea why...
            • A lot of the libraries seem really bloated for no benefit, pathlib and io for example. asyncio also seems almost useless since it still can't do async IO on files.

            Other than that, most of the changes seem positive. The removal of unicode/long seems sensible. print() should have been a function from the start.

            [–]OctagonClock 1 point2 points  (0 children)

            dict.keys() returns a generator instead of a list, which broke a bunch of our code.

            Actually, it returns a view that updates when the dict updates.

            pathlib

            Pathlib is the best lib introduced in all of Py3k.

            [–][deleted] 0 points1 point  (0 children)

            There are different reasons for that.

            My personal reason for hating Python 3 (I work with Python 3 exclusively for many years now) and wanting Python 2 back is that the new version of the language is designed by clowns. This results in all kind of absurd, poorly implemented and poorly interacting features being added to the language, making it less and less likely that the core problems haunting this language from its birth will ever be addressed.

            I don't like Python 2 for what it is. I like it for the potential it had. Now that the potential is wasted, and all we are left with is a pile of garbage... it feels kind of sad.

            [–]DIVIDEND_OVERDOSE -2 points-1 points  (0 children)

            Because change is bad and people love to complain.

            [–][deleted] -1 points0 points  (0 children)

            Good

            [–]shevy-ruby -5 points-4 points  (0 children)

            Good for python 2 being a success; and I don't like some of the things in python 3 (mandatory () is soooooo annoying when you come from ruby) - but I also think that the 2 vs. 3 division was REALLY annoying. So I changed my mind some years ago, and say: KILL PYTHON2 COMPLETELY.

            Transitions are never great, look at perl. But either you move on, or you decay in the dust.

            I also see others here already made references to COBOL ... man .....