2 ms·

Author here: > It is true however that he was super pessimistic about Python 3 and was one of the leading voices for a long time talking down Python 3. I stro

Author here: > It is true however that he was super pessimistic about Python 3 and was one of the leading voices for a long time talking down Python 3. I strongly advocated against underestimating the cost of migration, which is also why I argued for bringing back the `u` prefix for strings to make supporting 2.x and 3.x work at the same time. I also built a tool to modernize Python codebases to support both at once. I think in retrospective I was not wrong about that the transition will take time. I don't think the migration to 3.x would have been any faster if I would have pretended it's easy :)

sitkack 4y ago
I followed your arguments, and frankly you continue to be more right over time. We happened to get lucky that Python and Data Science and then by extension AIML aligned because that really did carry Python over the 2-3 chasm. There should be a book in the style of the Mythical Man Month about discontinuous tech stack transitions (Python 2 to 3). Or ecosystem splitting issues (Phobos/Tango), or Package Management (C++). I don't view your engineering mindset as pessimism, I view it as realist. My take is that engineering is 80% failure mitigation, but if we don't do solid failure analysis we will only get lucky 1/5 the time. I think this is why we see so many software projects fail. Backporting Python3 features to Python2 would have made the transition go faster for everyone. You are on a hike with a bunch of scouts, huge range of gear and physical and emotional ability, you don't bitch at the fast ones to go slower, you don't bitch at the slow ones to go faster, you redistribute the load, and if the fast ones are still fast, you give them enough supplies to start setting up camp ahead of the rest of the group.
andrewstuart 4y ago
Even today Python 3 makes conversion between bytes and Unicode and ascii too hard. After many years Python programming I still have to look up which direction encode and decode point when converting bytes/strings/whatever. Python 3 still suffers from not having simple, explicit functions for converting such a string_to_ascii or whatever. Python was meant to be about providing explicit obvious one way to do something but encode and decode are a giant fail in this area and I think this is a primary reason why Python 2 to Python 3 was so hard for people. I am quite pessimistic about this. Still not fixed or even acknowledged as a problem today. If developers have to keep looking something up over and over then the developer is thick or the programming language has failed usability in that area.
- js2 4y ago
  I've been using Python since 1.5.2. I find converting a Python 2 codebase to Python 3 fairly challenging because it cannot be done mechanically. You have to carefully consider each string and whether it is bytes or a string. But for new Python 3 code, I do not find it painful at all. The reason for the transition (to distinct byte/string types) was that it was too easy to confuse the two in Python 2. Is your critique that you don't feel that the distinct types are needed, or that it's too difficult to convert from bytes to string and vice-versa? I'm not sure how it can be much easier: b"".decode("utf8") and "".encode("utf8") are quite clear to me. Is it just that decode/encode are hard to remember? You could use str(b"", "utf8") and bytes("", "utf8"). Careful with str(b"", "utf8") though because if you leave out the encoding you'll get back a string, but probably not the string you want.
  - andrewstuart 4y ago
    >>> I'm not sure how it can be much easier: b"".decode("utf8") and "".encode("utf8") are quite clear to me. They look arcane and unclear to me. Which direction is encode and which is decode? What does decode and encode actually mean? There should be some hint in the function name. Here is a question for you…. for the example you give, what are all the possible permutations of every possible component of each command? What happens if you prefix encode with b? What if you don’t prefix decode with b? What other possible values can go in the brackets? Can I encode and decode all types of input?
    - tremon 4y ago
      What's stopping you from finding the answers to these questions yourself? What happens if you prefix encode with b? >>> b'these are bytes'.encode('utf8') Traceback (most recent call last): File "<stdin>", line 1, in <module> AttributeError: 'bytes' object has no attribute 'encode' What if you don’t prefix decode with b? >>> 'this is a string'.decode('utf8') Traceback (most recent call last): File "<stdin>", line 1, in <module> AttributeError: 'str' object has no attribute 'decode' What other possible values can go in the brackets? Can I encode and decode all types of input? https://docs.python.org/3/library/codecs.html#standard-encodings https://docs.python.org/3/library/codecs.html#standard-encod... Proper Unicode handling is hard for developers because many prefer not to think about it at all. Do you have an example of a language that has a Unicode conversion API that does work for you?

sitkack 4y ago

I followed your arguments, and frankly you continue to be more right over time. We happened to get lucky that Python and Data Science and then by extension AIML aligned because that really did carry Python over the 2-3 chasm. There should be a book in the style of the Mythical Man Month about discontinuous tech stack transitions (Python 2 to 3). Or ecosystem splitting issues (Phobos/Tango), or Package Management (C++). I don't view your engineering mindset as pessimism, I view it as realist. My take is that engineering is 80% failure mitigation, but if we don't do solid failure analysis we will only get lucky 1/5 the time. I think this is why we see so many software projects fail. Backporting Python3 features to Python2 would have made the transition go faster for everyone. You are on a hike with a bunch of scouts, huge range of gear and physical and emotional ability, you don't bitch at the fast ones to go slower, you don't bitch at the slow ones to go faster, you redistribute the load, and if the fast ones are still fast, you give them enough supplies to start setting up camp ahead of the rest of the group.

andrewstuart 4y ago

Even today Python 3 makes conversion between bytes and Unicode and ascii too hard. After many years Python programming I still have to look up which direction encode and decode point when converting bytes/strings/whatever. Python 3 still suffers from not having simple, explicit functions for converting such a string_to_ascii or whatever. Python was meant to be about providing explicit obvious one way to do something but encode and decode are a giant fail in this area and I think this is a primary reason why Python 2 to Python 3 was so hard for people. I am quite pessimistic about this. Still not fixed or even acknowledged as a problem today. If developers have to keep looking something up over and over then the developer is thick or the programming language has failed usability in that area.

js2 4y ago
I've been using Python since 1.5.2. I find converting a Python 2 codebase to Python 3 fairly challenging because it cannot be done mechanically. You have to carefully consider each string and whether it is bytes or a string. But for new Python 3 code, I do not find it painful at all. The reason for the transition (to distinct byte/string types) was that it was too easy to confuse the two in Python 2. Is your critique that you don't feel that the distinct types are needed, or that it's too difficult to convert from bytes to string and vice-versa? I'm not sure how it can be much easier: b"".decode("utf8") and "".encode("utf8") are quite clear to me. Is it just that decode/encode are hard to remember? You could use str(b"", "utf8") and bytes("", "utf8"). Careful with str(b"", "utf8") though because if you leave out the encoding you'll get back a string, but probably not the string you want.
- andrewstuart 4y ago
  >>> I'm not sure how it can be much easier: b"".decode("utf8") and "".encode("utf8") are quite clear to me. They look arcane and unclear to me. Which direction is encode and which is decode? What does decode and encode actually mean? There should be some hint in the function name. Here is a question for you…. for the example you give, what are all the possible permutations of every possible component of each command? What happens if you prefix encode with b? What if you don’t prefix decode with b? What other possible values can go in the brackets? Can I encode and decode all types of input?
  - tremon 4y ago
    What's stopping you from finding the answers to these questions yourself? What happens if you prefix encode with b? >>> b'these are bytes'.encode('utf8') Traceback (most recent call last): File "<stdin>", line 1, in <module> AttributeError: 'bytes' object has no attribute 'encode' What if you don’t prefix decode with b? >>> 'this is a string'.decode('utf8') Traceback (most recent call last): File "<stdin>", line 1, in <module> AttributeError: 'str' object has no attribute 'decode' What other possible values can go in the brackets? Can I encode and decode all types of input? https://docs.python.org/3/library/codecs.html#standard-encodings https://docs.python.org/3/library/codecs.html#standard-encod... Proper Unicode handling is hard for developers because many prefer not to think about it at all. Do you have an example of a language that has a Unicode conversion API that does work for you?