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.
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.
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.
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.
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.
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.
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.
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.
For 2to3 to confidently convert py2’s list-returning
items()to py3’s iterator-returningitemsw/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 sometimesstringis used out of habit for all text content, when[]bytecan sometimes still be the right thing there. There are[]byteversions of lots of string tools, you can mutate[]bytesin-place, sometimes you can reuse the space, and you avoid copies. There are certainly times you just have to usestring, like for map keys, or you want to ‘cause of immutability, the handy operators, etc., orstring’s just the most convenient type f/short or unchanging data, or (often) a lib usesstringso 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 onstring<=>[]byte-itis.Based off my Python 2 to 3 port, the reasoning I used for knowing when to opt for
str(which should have been namedtextIMO) orbytesis: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.
Worth noting that modernize is probably a nicer tool to use than 2to3.
No, why are you? If you don’t need it, why aren’t you using
.iteritems()?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.
I think you missed the part where 2to3 automagically made that dumb code.
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.
if you don’t have the
print_functionimport in Python 2, then that print transformation is right.print(1)prints(1)in Python 2 w/o the future import, but prints1in 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-futurerather than2to3. 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.oh?
Looks about the same to me.
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 prints1 2.So? This isn’t the case here. tedu’s point still stands: 2to3 added superfluous parenthesis.
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.
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.