1. 10

  2. 5

    For 2to3 to confidently convert py2’s list-returning items() to py3’s iterator-returning items w/out any chance of introducing bugs, it’d have to prove you’re not modifying the dict inside the loop. I’m inclined to give 2to3 that one.

    I’ve been kicking around a draft of a post about Go memory tips, and one is about string/[]byte; long story short, I get the sense sometimes string is used out of habit for all text content, when []byte can sometimes still be the right thing there. There are []byte versions of lots of string tools, you can mutate []bytes in-place, sometimes you can reuse the space, and you avoid copies. There are certainly times you just have to use string, like for map keys, or you want to ‘cause of immutability, the handy operators, etc., or string’s just the most convenient type f/short or unchanging data, or (often) a lib uses string so you need to, too. For all those reasons and more this is not an assessment of Ted’s code (that I haven’t seen!), just a general observation on string<=>[]byte-itis.

    1. 1

      Based off my Python 2 to 3 port, the reasoning I used for knowing when to opt for str (which should have been named text IMO) or bytes is:

      • Do you want to display the content (printing), or does it represent human-readable content (JSON)? You probably want text.

      • Are you only transporting data from one place to another, without any processing? You probably want bytes

      • When unsure, you probably want text. bytes should mainly appear at the border of your program (reading input, writing output), but are harder to manipulate correctly in most cases.

    2. 4

      Worth noting that modernize is probably a nicer tool to use than 2to3.

      1. 4

        Why are you sticking a list around items?

        No, why are you? If you don’t need it, why aren’t you using .iteritems()?

        Not sure what the deal with the extra parens for print is about.

        Yeah, why are you writing parens around the arguments to your print statement? I you like the print function, import it from __future__.

        The difficulty of supporting strings and bytes in a natural fashion is intrinsic, but may be obscured in Python 2 if you are lucky enough to only deal with ASCII.

        The fact that pygments is slower on Python 3 is a failure. It would be nice if it could be fixed and this person could be brought into py3k18.

        1. 4

          I think you missed the part where 2to3 automagically made that dumb code.

          1. 4

            I think he is actually talking about the code 2to3 was given. The print statement was given an expression in parentheses. It just looked like a function call. Also d.iteritems is the python2 way of saying d.items.

            1. 2

              if you don’t have the print_function import in Python 2, then that print transformation is right.

              print(1) prints (1) in Python 2 w/o the future import, but prints 1 in Python 3.

              I don’t know if the list wrapping is needed considering its usage in the iterator. Strictly speaking the list wrapper is the right way to go, but I don’t think it could affect anything apart from memory usage.

              Personally, I had much better luck using python-future rather than 2to3. But a lot of needed Python 3 changes require thinking, so at best these tools find things you need to change. But you’ll need to rework the translation.

              2to3’s existence and intended use case as a “automatic translator” between the languages is the biggest artefact from the Python 3.0 mindset that causes these blogposts to still exist.

              1. 2


                > cat test.py
                > python2.7 test.py
                > python3.6 test.py

                Looks about the same to me.

                1. 3

                  The difference is when you say something like print(1, 2). In python2, it prints the tuple (1, 2). In python3 it’s a function call with two arguments and prints 1 2.

                  1. 3

                    So? This isn’t the case here. tedu’s point still stands: 2to3 added superfluous parenthesis.

                    1. 3

                      The author added superfluous parenthesis and 2to3 failed to remove them. This is easily fixed in the source code either by making print a function or by removing the parenthesis, and the py2 code will be better off for it.

                  2. 2

                    ah, you’re totally right, my bad. Like sibling comment mentions, it’s for tuples where the behavior becomes a bit different. Added parens are totally useless.