1. 18

    Benson Leung at Google tests 3rd-party cables for spec-compliance and posts the results as amazon reviews

    Nathan K also has a series of tests

    Not aware of anyone analyzing the firmware specifically however. I’d imagine that the limited on-board storage would make infection difficult but not impossible.

    1. 7

      Benson was a college buddy of mine back in engineering school. So funny to see he get quasi-famous over this, but knowing Ben, it’s pretty fitting.

    1. 11

      Only 9 years after the release of python 3. Maybe in another 9 years I can stop having to install python 2 + a bajillion libs on my system along with python 3.

      1. 4

        I think it’s more likely that in 9 years there won’t be a python 3, or possibly a python 2. This switch has been so painful and sucked so much air out of the community that it is putting the future of python itself into jeopardy.

        1. 9

          This would be terrible, if it were true.

          I was programmatically going through a massive list of python packages in use at our place, and it turned out that only a few of those packages was incompatible with Python 3. And for those, many were unmaintained (with a maintained, python 2 and 3 compatible fork available, so basically packages you wouldn’t want in your dependencies anyway). Basically I ended up with almost no incompatible dependencies.

          Sure enough, 9 years ago it was a bumpy ride. But the last 2-3 years are not like this at all for me. So when you are writing such a comment, I would like to know if you can bring up issues with regards to the Python 2-3 split that you experienced in the past 2 years. Because talking about the Python 3.0 release is so 2008.

          Sure 8 years sounds long, but let’s have a look at the timeline. Python 3.0 was released in 2008. Python 2.7 in 2010. Python 3.4 (released in 2014) is the first release, that I would say could compete with Python 2.7 in terms of stability and backwards compatibility. We are now in 2017 and debian-stable now features Python 3.4. So now is the time that Python 3 adoption can actually start. I would assume that Python 2.7 got adopted also not in 2010, but ~2013 roughly speaking. So, we are experiencing a delay here in adoption, but the delay is much shorter, than 8 years. We could have wished for it to show up 1-2 release cycles earlier (that would be 2-4 years), but really, the python devs had our back here, releasing 2.7.10 in 2015, many linux distributions ship python 2 and python3 in parallel, making a migration also much easier.

          I am not a Python fanboy, but a user who enjoys the ecosystem. And I don’t feel like Python 3 is a huge problem in the community. [*]

          Why Drop Support?

          Python 3 brings features to the table that just make library development better. Keyword-only arguments are just one such example that library authors can use to make minor changes to the API not break user code by accident. The Python releases have also seen a bunch of development from 3.4 to 3.6 that you can’t benefit from if you use Python 2. This starts with the addition of missing functionality in the standard libraries, better syntax, exception reraising made easier, ordered-by-default dictionaries, async, etc.

          [*] maybe those who have seen this as a problem have left longtime ago for Go. But If you did port your application from Python 2 to Go, you don’t really have a point criticising the steps needed to Port an application to Python 3.2 (or even easier to Python 3.4).

          1. 2

            many linux distributions ship python 2 and python3 in parallel, making a migration also much easier.

            I don’t disagree with your general point, but to me, this bit is a bug, not a feature. I hate that I end up with two versions of Python, two versions of iPython, etc. It’s annoying and it forces me to think too much about which version I’m using. This also means that I’m much more likely to just use Python 2 because that’s the only that’s just called “python”, so things will work with it and I don’t have to remember to add a “3” to every command I run (ipython3, pip3, and so on).

            1. 1

              Hmm, maybe your workflow is different from mine. I usually create a virtual environment virtualenv --python=python3.4 myvenv or virtualenv --python=python2.7 myvenv and then the given python executable is the default python after

              source myvenv/bin/activate

              I.e.

              virtualenv --python=python3.4 myvenv
              . myvenv/bin/activate
              python --version
              

              yields Python 3

      1. 3

        I’d like to say this event would be a wakeup call, but I can’t even write that without smirking.

        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.

          1. 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

                    1. 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).