1. 23

Don’t agree with many of the author’s arguments, but the conclusion is solid. 8 years of Python 3 without serious adoption.

  1.  

  2. 35

    The killer features for Python 3, IMHO, are the clean Unicode/bytes distinction and the normalization of the object model.

    The problem with Python 3 is, of course, that Python 2 is “good enough”.

    1. 7

      I have spent the last couple of days wrangling with generators and co-routines in Python2. I wish the project I’m working on was started in Python3 (considering it’s 2 years old). Python3 is light years ahead in terms of async programming features baked in.

      1. 5

        You can start calculating by looking at Python 3.0’s release date (in 2008) and then wonder why it hasn’t been adopted within 8 years. But I think of this differently.

        The first viable candidate for a Python 3 migration is Python 3.4. It’s the release you pick, when you want to maintain a 2 and 3 compatible code base, which is what many libraries need to do. And it is kind of known in the community that 3.0 had a few regressions in terms of stability and speed over 2.7 (never used 3.0 so this is hearsay, nevertheless even that hearsay would keep me from migrating 2.7->3). Now Python 3.4 was released in 2012. which is basically 4 years ago. 4 years is a long time, but it definitely isn’t 10 years.

        The problem with Python 3 is, of course, that Python 2 is “good enough”.

        Indeed, and during Python 3’s development and release cycle, Python 2.7 also saw improvements, patches, etc. which means, that it didn’t immediately started to decay, like any other unmaintained software would.

        Now, if you run Python on a Desktop, it was definitely possible to use Python 3.4 as it was released. But if you run Python on servers, you are bound by the release schedule of your distribution. So until you migrated from Debian wheezy to Debian jessie, you were essentially bound [$] to Python 2. Coincidentally, 2015 was the year when I started to hear many success stories at Python conferences on the hallway tracks: “We did it”, or “I was surprised how easy it was”. For many, now is the time that many passionate Python devs realize: Ah, I finally could use Python 3, let’s see if my code will work on it. And suprise, surprise it works.

        [$] And since Python is often used in linux distributions, you are not as likely to manually roll out an official release but stick to the distribution-provided one. If you would run Haskell for example, you would probably have a independent update cycles for your linux distribution and Haskell.

        1. 5

          clean Unicode/bytes distinction

          The author argues it isn’t clean, and it’s actually obnoxious, counterintuitive, and frustrating.

          In an attempt to make their strings more “international” they turned them into difficult to use types with poor error messages. Every time you attempt to deal with characters in your programs you’ll have to understand the difference between byte sequences and Unicode strings.

          If we have a string and a bytes type then when we [concatenate them] we get an error, and [using .format()] we get a repr formatted byte string.

          I agree with the author on this, even if the rest is classic Zed Shaw angry rambling. It’s a huge pain in the ass. Go has a clean unicode / bytes distinction, python3 does not. Or maybe it does, and I’m just a foolish peasant for wanting to write scripts in python without screwing around with unicode.

          1. 12

            It’s a strange argument. I own a codebase that works in both 2 and 3, and by the far the most annoying errors I have to chase around are Python 2’s unicode/bytes confusion. Python 3’s hard distinction is a much better experience for me, and leads to cleaner code with fewer “just in case” calls to .decode() and .encode().

            1. 2

              Or maybe it does, and I’m just a foolish peasant for wanting to write scripts in python without screwing around with unicode.

              I have been writing scripts in Python 3 for years now and haven’t experience any issues like this. Can you show an example?

              1. 2

                The first script I tried to write in python3 was working with hex, which appears to be a fairly pathological case. As such, I remember it vividly. This is approximately what happened:

                $ python3
                >>> 'text'.encode('hex')
                Traceback (most recent call last):
                  File "<stdin>", line 1, in <module>
                LookupError: 'hex' is not a text encoding; use codecs.encode() to handle arbitrary codecs
                >>> import codecs
                >>> codecs.encode('hex', 'text')
                Traceback (most recent call last):
                  File "<stdin>", line 1, in <module>
                LookupError: unknown encoding: test
                >>> codecs.encode('text', 'hex')
                Traceback (most recent call last):
                  File "/usr/local/Cellar/python3/3.5.2_3/Frameworks/Python.framework/Versions/3.5/lib/python3.5/encodings/hex_codec.py", line 15, in hex_encode
                    return (binascii.b2a_hex(input), len(input))
                TypeError: a bytes-like object is required, not 'str'
                
                The above exception was the direct cause of the following exception:
                
                Traceback (most recent call last):
                  File "<stdin>", line 1, in <module>
                TypeError: encoding with 'hex' codec failed (TypeError: a bytes-like object is required, not 'str')
                >>> codecs.encode(b'test', 'hex')
                b'74657374'
                >>> h = codecs.encode(b'test', 'hex')
                >>> [h[i:i+2] for i in range(0,len(h),2)]
                [b'74', b'65', b'73', b'74']
                >>> ' '.join([h[i:i+2] for i in range(0,len(h),2)])
                Traceback (most recent call last):
                  File "<stdin>", line 1, in <module>
                TypeError: sequence item 0: expected str instance, bytes found
                >>> ^D
                $ python2
                
                1. 2
                  >>> import codecs
                  >>> codecs.encode('text'.encode(), 'hex')
                  b'74657874'
                  

                  End-to-end it’s not all that bad. What would it be like in any other language that actually distinguishes text and bytes?

                  $ python3
                  >>> 'text'.encode('hex')
                  

                  It’s usual for encoding names to be character encodings: UTF-8, BIG5, ASCII. Does hex really fit there?

                  >>> codecs.encode('hex', 'text')
                  Traceback (most recent call last):
                    File "<stdin>", line 1, in <module>
                  LookupError: unknown encoding: test
                  

                  Seems like test and text got a little mixed up here in the transcript.

                  >>> h = codecs.encode(b'test', 'hex')
                  >>> ' '.join([h[i:i+2] for i in range(0,len(h),2)])
                  Traceback (most recent call last):
                    File "<stdin>", line 1, in <module>
                  TypeError: sequence item 0: expected str instance, bytes found
                  
                  >>> h = codecs.encode(b'test', 'hex')
                  >>> b' '.join([h[i:i+2] for i in range(0,len(h),2)])
                  b'74 65 73 74'
                  

                  Beware the FUD.

                  1. 3

                    It’s usual for encoding names to be character encodings: UTF-8, BIG5, ASCII. Does hex really fit there?

                    No, it did not. Python 2 also has a rot13 codec (for the this module I suppose), which was probably also axed.

                2. 1

                  Same here, I’ve spent a few days tracking down unicode related bugs in Python 2, so far Python 3 has been much better when it comes to unicode. (or maybe I just didn’t hit the edge cases yet)

              2. 3

                I would divide Python unicode users into three groups:

                1. For English speaking beginners and those writing simple scripts that don’t need unicode, Python 2 wins by a mile.
                2. For non-English speaking beginners, Python 3 definitely wins, but probably not by all that much as most non-English speakers are used to painful internationalization issues (I know, this isn’t fair, but it’s true).
                3. For projects which have to consider unicode from the start, Python 3 is better. However, the lack of compatibility with older Python 2 libraries is so painful that it cancels out any benefit that you can get from better unicode support.

                IMO, Python 3 has been a huge failure, and while I’m sure it’s painful for the core development team, it should be dropped sooner rather than later.

                1. 8

                  As a Korean, I have a problem with this:

                  For non-English speaking beginners, Python 3 definitely wins, but probably not by all that much as most non-English speakers are used to painful internationalization issues (I know, this isn’t fair, but it’s true).

                  This is not true, at least not here. I really can’t imagine how it would be true elsewhere though. If someone is “used to” painful internationalization issues, how can that one be a beginner? To state this the other way, if there are such “know internationalization” beginners, there must be more “don’t know internationalization” beginners.

                  1. 2

                    A beginner who’s used computer programmers is used to having to use an ascii-fied version of their name in popular computer programs. Eevee’s response post gives the example:

                    Hi, my name is Łukasz Langa. .agnaL zsaku�� si eman ym ,iH

                    In my experience any beginning-programming Łukasz who has used a computer for a while is used to Łukasz randomly turning into ��ukasz, and so won’t find it particularly surprising or puzzling that their program does that.

                    1. 2

                      I agree, but I still don’t see how that makes Python 3’s definite advantage compared to Python 2 “not all that much”.

                      1. 2

                        so won’t find it particularly surprising or puzzling that their program does that

                        Your argument is “it sucks everywhere therefore we shouldn’t even try to do better”? I think that is sad. And international names might also happen when you’re a native speaker: your form application might be used by a foreigner and then it breaks in surprising ways (kinda like Amazon fails to deliver diacritics). I don’t think that having a ticking time bomb bug in your program is a good state to be in and getting a Python 2 program to be all-Unicode is rather hard.

                        1. 2

                          My argument is “it sucks everywhere so doing it better is clearly not something people are that bothered about, in a revealed-preferences sense”. In an abstract sense we should all make our programs better in all respects. Concretely, correct handling of non-ascii should probably be a low priority for language designers, since the available evidence suggests it’s a low priority for language users.

                    2. 3
                      1. For English speaking beginners and those writing simple scripts that don’t need unicode, Python 2 wins by a mile.

                      That is an argument, until you run into some bug because that piece of pure-English text contained some unicode ? symbols. Also, I don’t see how beginners would have a very much time in Python 3 because of the byes vs strings distinction.

                      A definitive change for the worse for beginners was the laziness-by-default changes for many functions. Really makes it harder for them to experiment in the Python prompt.

                      1. 2

                        To be honest, handling emojis is not a beginner task. Running into bugs is not a beginner task. Teaching resource should be carefully prepared so that learners do not run into bugs.

                        1. 1

                          With controlled “input data”, I don’t see how Python 3’s unicode handling would be more hostile to beginners.

                    3. 2

                      But what do you think Python3 is killing?

                      It’s clearly killing python2, but programmers, instead of redeveloping their python2 knowledge inside python3 are considering other, more durable languages.

                      I’ve still got C and perl programs more than twenty years old that are running in production (and on the Internet).

                    4. 54

                      Ugh. I’m pretty happy sticking with Python 2, but this post is so bad I’m tempted to switch to Python 3. Even as a joke the Turing complete section is just stupid.

                      1. 23

                        I couldn’t tell whether the Turing Complete section was a joke or just profoundly confused, to be honest. Conflating the language with the bytecode, claiming that one VM can’t run the bytecode generated by another language (or maybe complaining that the bytecode changed? or that there’s no py2 compiler targeting py3 bytecode?), and trying to tie that to a fundamental property that even “languages” like SQL and Excel have ….

                        It was all very muddle-headed.

                        Don’t get me wrong, I know he’ll claim that it was a joke, later. That’s not in question. I’m just not sure if it actually is a joke.

                        1. 20

                          I don’t think this is meant as a joke. The “post” is a chapter in his book Learn Python the Hard Way.

                          Difficult To Use Strings

                          Wait.. what? Strings are a mess in Python 2. They have been cleaned up in Py3.

                          Python 3 Is Not Turing Complete

                          No comment.

                          Purposefully Crippled 2to3 Translator

                          It took me about one day of work to port a 70k lines django application to Py3 with the 2to3 tool. That’s was one year ago. Since then I’ve only found two bugs caused by the conversion. Doesn’t seem that bad to me.

                          Too Many Formatting Options

                          Yes, I can agree with that. This is the only valid criticism in that chapter.

                          1. 15

                            I agree, but just as a data point, it’s taken about 3 people-weeks for us to port a large (~200kloc) Django application (over the course of several months).

                            The points that made this take a while:

                            • We tried to maximize the amount of changes that were Py2 + Py3 compatible. This meant pulling things in over time, heavy usage of six, and catching a lot of bugs early on. Highly recommended for easy reviewing by third parties. For example: a couple changesets that were just “use six for more imports”.

                            • we deal with many different encodings, and a lot of old text-to-bytes conversion code was pretty brittle. Py3 forced us to fix a lot of this

                            • imports! 2to3 generated way too many false positives for our taste (hard to review the real changes), so it took a while to find the right solution (for us: a monkey-patched six that would minimize changes)

                            • changes of standard API from lists to iterators generated a decent amount of busy work. Changes for the better, though.

                            • Handling binary files. Here, too, we were often doing the wrong thing in Py2, but it would “just work” before.

                            • Lots of dependencies that we needed to upgrade to get the Python 3 support.

                            • Pretty minor things around bytes’s defautl __str__ method. For example, checking the output of a process call, we would do if output == "'0'", and that would fail because `“b'0'” != “‘0’” but that turned out to cause more issues down the road.

                            • issues around pickling + celery. Our solution mostly centered around lowering usage of pickle even more (dangerous)

                            • deployment issues. Juggling Python 2 tooling and Python 3 tooling in the CI pipeline would sometimes mess things up.

                            1. 4

                              I can only recommend https://pypi.python.org/pypi/modernize

                              Instead of translating x.iteritems() to x.items(), it translates it to six.iteritems(x), and adds the six import. Fixes 80% of the boring stuff and you only need to focus on unicode/bytes, etc.

                              1. 2

                                The idea of Python 3 was to make iteration cleaner the easier to read and understand. Now we have to insert calls to six in every loop and for every string. The result is hideous code that’s harder to read, not easier.

                                1. 2

                                  I was writing this because

                                  We tried to maximize the amount of changes that were Py2 + Py3 compatible

                                  If that is not your objective, you can just use 2to3 and be ready.

                                  By the way, I really do not understand, why the CPython devs haven’t kept iteritems() as an alias to items() in Python 3 with a deprecation warning to be removed in Python 4. I cannot imagine that it would have been a massive maintenance effort. But on the other hand, making a function call instead of a method call is not rendering code unreadable. I have never heard a Python dev complain about calling str(foo).

                                  Essentially, Python 3 adoption has not been slow because of “readability”, but because Python 3 bundles fairly boring changes (iteritems->items) with this massive unicode change (requiring quite a few changes to code bases) and few breathtaking new features that weren’t available in 2.7. This changes at the moment with Async, matrix multiplication operators, etc.

                            2. 3

                              Python 3 Is Not Turing Complete

                              No comment.

                              Did you read the note?

                              1. 12

                                If anything, the note make it seems like he’s really serious about his Turing FUD.

                            3. 9

                              Joke or not, the fact that we even have to ask that question significantly harms the credibility of the article.

                            4. 5

                              Just out of curiosity, why are you sticking with Python2 for now? At this point all of the major libraries have been ported to be 2/3 compatible. In addition, while there aren’t any huge new features in Python3 (besides the byte/Unicode separation) there has been an accumulation of small quality of life improvements that from my point of view make it very much worth it to switch.

                              1. 1

                                Not sure about the comment author, but I’ve personally moved over some of my open source libraries to support both python 2 and 3. Moving larger project is tricky though as it involves updating the language, all dependencies and forking the ones that don’t support python 3.

                              2. -7

                                haha

                              3. 11

                                I think a lot of you have missed the point of this article, and some of you have skipped using your head and jumped straight to making low effort, snarky comments (and have been downvoted).

                                It’s also unfortunate that Zed chose to write the section on Turing-completeness (which is an attempt at satire btw, look at the highlighted text 50px beneath it (I agree it’s dumb though)) because people are piling on that and using it to instantly dismiss his arguments.

                                Zed is writing this from the perspective of someone teaching people to program for the first time. In particular, first time programmers:

                                • may not know what a byte is
                                • do not know what Unicode is
                                • do not care what bytes or Unicode are
                                • do not appreciate it when people try to shove this relatively advanced knowledge on them while they’re adding numbers together

                                In addition, I don’t think it’s controversial to say that python is only legitimately good in two ways (and meh/ok at everything else):

                                • it’s easy to learn
                                • there’s tons of libraries

                                These are important for first time programmers, and are probably why Python is so popular today.

                                Zed highlights that python 3 is less easy to learn than python 2 because it forces you to think about whether your strings are unicode or just bytes. A first time programmer does not understand what this means, they don’t want to understand what this means (yet), and it’s not helpful for them to understand what this means. Zed also highlights that it’s possible to implement strings in such a way that nobody has to care or understand what this means, and that the python developers have chosen to make this a problem.

                                I’d also like to note that only a tiny (but disproportionately common) subset of computer science/programming actually needs you to understand unicode. I’ve been programming for over 10 years and I’ve never had to write unicode aware code.

                                One of his other arguments is that the future of python 3 might not be so bright, because it’s harder to learn and too difficult for most people to migrate, so people considering learning it will be better off investing their efforts in a better language.

                                Finally, he wraps it up by saying that the python developers are perhaps forgetting why python 2 was so successful in the first place - its easiness.

                                I don’t think his arguments are unreasonable.

                                1. 12

                                  the section on Turing-completeness (which is an attempt at satire btw, look at the highlighted text 50px beneath it

                                  That’s a new addition. Which means my prediction from elsewhere in this thread:

                                  Don’t get me wrong, I know he’ll claim that it was a joke, later. That’s not in question. I’m just not sure if it actually is a joke.

                                  … was spot on.

                                  1. 7

                                    because people are piling on that and using it to instantly dismiss his arguments.

                                    It’s a long post and “ugh I hate Python 3”-type articles aren’t known for being insightful. I think it is perfectly reasonable to dismiss someone’s argument and save a few minutes of time if they say something that blatantly wrong. You say it is satire, but what exactly is he satirizing? I only know Zed for his cringey “Rails is a Ghetto” rant so forgive me if I don’t automatically assume he knows what he’s talking about or is writing in good faith.

                                    1. 2

                                      He is the author of Learn Python the Hard Way, which is a pretty great tutorial I’ve recommended to people in the past. But there really needs to be a Python 3 version…

                                        1. 1

                                          Ah, never knew this was released, thanks!

                                          1. 1

                                            It was mentioned in the article, along with the sort of ultimatum that he won’t publish it until he considers Python 3 friendly toward beginners.

                                    2. 2

                                      Zed highlights that python 3 is less easy to learn than python 2 because it forces you to think about whether your strings are unicode or just bytes.

                                      How does it force you to do that?

                                    3. 16

                                      Frankly, this is not a very informative or useful writeup. In some places it’s wrong (like the Turing thing and the statement that you can’t have p2 and p3 side by side on a machine). Is it humor? I can’t tell.

                                      Having only “ported” a small program that uses numpy, matplotlib and scipy my experience is limited but here are my takeaways

                                      1. That string/byte thing can get very annoying. Fortunately, we have stackoverflow. Still not clear why we had this change though.
                                      2. It’s pretty messy to support both Python2 and 3 - the mechanisms (e.g. six) make the code look very ugly. I had the luxury of just being able to move wholly to p3
                                      3. The differences between p3 and p2 are not that great until you get into the new esoteric features of p3
                                      4. A lot of people have moved to p3, making it easier and easier to move

                                      In short - is it an improvement? I don’t know, but if you are writing new code, do it in p3 and if you stop reading rants about p3, you’ll have more productive time on your hands.

                                      *I put ported in quotes because I rewrote major portions of the code as I was porting - but I would have done that even if I hadn’t changed to Python3

                                      1. 8

                                        I suppose you did not work a lot with other language than english in python 2. It’s a nightmare for me.

                                        Did you look on the official python3 porting guide ? https://docs.python.org/3/howto/pyporting.html

                                        1. 2

                                          ~~Hey! No, I have not had to do translation - why is this particularly difficult with py2 re py3? Thanks!~~

                                          (Sorry, I was dense, of course you need unicode string for non-ASCII char sets. All my work has been in scientific applications, some in genomics, where unicode is more of an annoyance - like “Damnit I just want standard bytes in my string” :) )

                                          1. 8

                                            unicode treatment is a nightmare in python 2 because of the silent conversion between unicode and bytes. All work well when sticking with ASCII characters, but as soon as you accidentally go out of this range for example using 'é', it throws UnicodeDecodeError at random places because the silent conversion work only for ASCII characters.

                                            At the opposite, in python 3, if you fail to do proper conversion it fails immediately and you don’t have a program which worked during a long time and suddenly broke on unicode string

                                            I understand well, if you never use unicode string, the fact bytes are kind of second class string is annoying for you

                                            1. 5

                                              I inherited a big app done in Python 2, Unicode issues were never considered. A year after I took over it finally went into production — and suddenly there were Unicode bugs everywhere. Even a year after that, they were still popping up in obscure corners.

                                              It was too huge to port, but the next three projects I started at that company were in Python 3. Unicode bliss.

                                              1. 1

                                                This is exactly it. If he hasn’t been bitten by the fact that bytes are sometimes compatible with unicode, he has been plain lucky.

                                                1. 1

                                                  if he use it in genomics things (always bytes and ascii), it is possible that he was never stroke by it

                                                  1. 1

                                                    Yes, sorry for being unclear – by “he” I meant Zed.

                                          2. 1

                                            the statement that you can’t have p2 and p3 side by side on a machine

                                            That’s not what that’s about. He talks about running both languages on the same interpreter/VM so there’s easy interoperability.

                                          3. 19

                                            I’m offended by reading a text that is 80% misuse of terminology, 5% whining about people not liking what the author does, 10% pretending that str vs unicode won’t bite you in the ass on Python 2 and 5% has a point.

                                            1. 7

                                              The Turing complete section is so wrong it hurts. Just to be clear–and I hope this isn’t necessary at lobste.rs–Python with nothing else but lambda and function calls is Turing complete. I’m not very familiar with Zed Shaw’s work, but that statement alone is enough to ensure that I’ll never recommend his book to new Python programmers

                                              1. 3

                                                I think he’s making some sort of weird joke, but I don’t really get it. Agree, it’s kind of insane.

                                              2. 8

                                                Zed’s stories call for a troll option in the flags.

                                                1. 8

                                                  SincereTroll?

                                                2. 4

                                                  I also disagree with the poster on “without serious adoption”.

                                                  I agree that the transition strategy has kept people on Python 2, but the big dependencies people use are now finally available on both languages. The big glaring hole is SCons.

                                                  People can start fresh development on Python 3 and people are. If we take the numbers at face value, 30% is disappointing but not negligible. And that’s while Python 2 is still supported. 2 years left now.

                                                  1. 2

                                                    2 years left now.

                                                    I can’t wait for the development to be picked up by some team not trying to sabotage the language.

                                                    1. 1

                                                      I think Python 3 only became a viable option for new projects over the past 12 months or so. It took a long time for libraries to add support. Right now you can start a new project, and most of the libraries will just work:

                                                      http://py3readiness.org/ https://python3wos.appspot.com/

                                                    2. 3

                                                      @tschellenbach

                                                      Don’t agree with many of the author’s arguments, but the conclusion is solid.

                                                      If you don’t agree with article’s arguments, it’s hard to offer it as support for a conclusion.

                                                      1. 3

                                                        one of the first steps when implementing a new language is to convert the new language into an existing language (like C) so you don’t have to write a full compiler"

                                                        There’s no difference between a translator and a compiler! Every compiled language compiles to a different, usually more low-level language. Hell, clang even compiles C to LLVM IR, not to machine code.

                                                        Translation is a fully solved problem.

                                                        There are definitely tools to make making compilers easier - but it’s absolutely not a solved problem. Writing compilers is complex and time consuming - especially when they are trying to generate readable and idiomatic python3.

                                                        1. 2

                                                          There’s no difference between a translator and a compiler!

                                                          I agree there’s no hard difference, but in terms of what people want out of them, it’s often useful to think of compilers and source-to-source translators as different types of systems. The latter typically try to map high-level constructs in the source language onto similar high-level constructs in the target language, and produce somewhat idiomatic output, which rules out large classes of compiler techniques that like to flatten high-level constructs into a lower-level soup, like SSA conversion. But yeah most systems that “translate” to C as a backend are in fact using it as a compile target, not trying to produce idiomatic high-level C.

                                                          1. 1

                                                            True! There is definitely a different connotation. I do think writing a translator could be just as hard as a compiler

                                                        2. 3

                                                          I have tremendous respect for Zed Shaw’s talents, but honestly I’m not buying this. Let’s be honest, Zed has moved on to other things - he wants to be playing guitar and painting and whatever else. He got dragged back into teaching Python mode because EVERYONE said “Hey where’s LPTHW for Python 3?”.

                                                          Python 3 is not a failure. The entire mainstream Python community is moving that way. I recognize that the “cold dark matter” programmers slaving away in the enterprise will be on 2.X for the next decade, but I think most of us will be using Python 3 in our projects within the next few years. We won’t have a choice as 2.X is EOL’d.

                                                          1. 3

                                                            Python 3 adoption is pretty much universally used when starting new projects and a lot of projects are on the road to migrate to python 3. There is also a significant (significant but not a lot) number of library which start to dismiss all python 2 support. And the unicode support of python 3 is a bless.

                                                            1. 3

                                                              A lot has been covered already, but I found circularity of complaining about only 30% adoption and advising against adopting it because of it particularly hilarious. How does he think things should get adopted if everyone should avoid until they do?

                                                              1. 2

                                                                There are some valid concerns there. It is a shame that with statements such as “Python 3 is not turing complete” right next to them they pretty much get lost.

                                                                1. 3

                                                                  This post is garbage. Don’t learn 3 as a beginner? Fine, I’ll agree with that. Don’t use it at all? I don’t know about that.

                                                                  Unicode/byte strings are annoying, sure. Learn how they work and move on. People break non-latin strings constantly, but when they’re using unicode strings by default it happens much less often.

                                                                  Complaining about running py2 bytecode in the py3 VM? How often do you run into that problem?

                                                                  1. 5

                                                                    At this point there are more 3-only libraries than 2-only libraries, and that’s only going to get more so. Beginners are better off starting with 3.

                                                                  2. 1

                                                                    I really appreciated Zed’s LPTHW book when I learned Python myself. It was incredibly helpful when I taught it to my students. I bought a copy to support his work. But this rant is ridiculous. The Turing Complete section? Who is he kidding?

                                                                    1. 1

                                                                      I think that in this chapter, Zed uses an unusual interpretation of Turing completeness that is worth considering:

                                                                      1. a language is Turing-complete (in the traditional sense) if it possibly could run any program that could be run by a Turing machine (of some finite size)

                                                                      2. a language is Turing-complete (in the extreme sense) if it actually, can right now, today, run code written in any language

                                                                      3. a language is Turing-complete (in the Zed sense) if it possibly could fall in category 2

                                                                      Most all languages fit #1. No language fits #2. Some languages fit #3. But based on his communication with the Python devs, Python 3 will never fit #3. There will always be a little blind spot (unless someone takes it upon themselves to run all Python 2 code on a 3 VM).

                                                                      I understand this viewpoint can be controversial, but I don’t feel he’s wrong (just a little hard to understand). Maybe we need to call it something else, like Rosetta-complete, Babel-complete, I’m not sure. It’s an interesting concept, but it’s also unfortunate he used a taken name.

                                                                      1. 1

                                                                        Currently you cannot run Python 2 inside the Python 3 virtual machine. Since I cannot, that means Python 3 is not Turing Complete and should not be used by anyone.

                                                                        Wat. This could be trolling, but in most likelihood Zed’s just out of his depth here. There are two fundamental issues with this line of reasoning:

                                                                        (0) Turing-completeness is about the ability to compute all partial computable functions. It says nothing about other things programmers care about, like I/O or even computational complexity!

                                                                        (1) If I understand correctly, the Python virtual machine doesn’t run Python - it runs Python bytecode. What’s preventing anyone from writing a compiler that translates Python 2 to Python 3 bytecode?

                                                                        1. 4

                                                                          Nothing prevents someone writing a from __python2__ import django. Python 3 is indeed turing complete and so it does have the ability to create unusably corrupt strings by concatenating the bytes of two strings in different encodings, or concatenating raw bytes onto the underlying representation of a string in an encoding-ignorant way, if that’s what you really want to do.

                                                                          The reason no-one’s written it is there’s no use case. There are two possible cases here: either the library you want to import actually handles strings correctly, by scrupulously maintaining a distinction between strings and bytes that python 2 doesn’t give it any help with, in which case porting that library to python 3 will be a) trivial and b) probably a relief for the maintainers. Or the library you want to import just sloshes a bunch of bytes together and hopes that it works out, in which case there’s no way to automatically un-confuse it; making the library handle strings/bytes correctly is going to require intelligent programmer input, and why would you want to use such a confused library in your python 3 code?

                                                                        2. 1

                                                                          Here’s the big question, what can we do to unify the Python ecosystem and solve this terrible in between state?

                                                                          1. 3

                                                                            Wait two years for py2 support to end?

                                                                            1. 2

                                                                              Do you think that will work? You drop support for maybe >90% of Python code running in production.

                                                                              1. 5

                                                                                Well, it’s going to happen. If your organization has an enormous python2-only codebase and you are not moving to Python3, then you’re accepting responsibility for maintaining a codebase that runs on software beyond EOL. The equivalent to building your business on software that only runs on Windows XP.

                                                                                You may think that someone will step up and continue maintaining the python2 codebase after EOL, and that very well may happen. That said, so far no one has come forward to lead such an effort.

                                                                                1. 2

                                                                                  You may think that someone will step up and continue maintaining the python2 codebase after EOL, and that very well may happen. That said, so far no one has come forward to lead such an effort.

                                                                                  Maybe people (read: companies) will just start using pyston or pypy then?

                                                                                  1. 1

                                                                                    For projects like ours it’s not much of a concern. We can take the time and effort to move from python 2 to 3. In fact we’ve already moved many libraries. I imagine this is much harder for people who’ve outsourced their development. Good luck getting a customer to invest in a language upgrade.

                                                                                  2. 2

                                                                                    Postgresql v8.4 was end-of-life in 2014. Does that mean there are no 8.4 DBs around any more? No, but it means that there’s pressure to upgrade, even if it means code changes, because the community is no longer willing to support it. So there are fewer 8.4 DBs now than there were then.

                                                                                    Python 3.0 was released over eight years ago. A decade of continued support for the old versions, with years' worth of notice of dropping support, is really about as conservative a schedule as you can expect from a volunteer-run organization.

                                                                                  3. 1

                                                                                    Python 2 support will end in 2020, so more like three years.

                                                                                  4. 2

                                                                                    Port libraries and programs to Python 3. Or just wait. We’re already past the tipping point - there are now more libraries that are 3-only than are 2-only - the transition is unstoppable at this point.