Ride the carousel of folly with a Python migration
1–10 of 36 posts
Re: Ride the carousel of folly with a Python migration
#2Re: Ride the carousel of folly with a Python migration
#3Re: Ride the carousel of folly with a Python migration
#4Re: Ride the carousel of folly with a Python migration
#5 for line in iter( handle.stdout.readline, '' ):
self.output.put( ( handle, line ) )
> This no longer terminated an emitted lots of odd values (one number repeatedly). It turns out it returns an empty b'' now when empty, as opposed to a ''. This could have been avoided had this API sensibly returned None instead of an empty string.For any observers, this is much more idiomatically written:
for line in handle.stdout:
self.output.put((handle, line))
That is, the default iteration over a file-like object is line by line. Frankly, I wonder how many Python programmers are aware that iter() has a two-arg form; this is the first time I've ever seen it used (and I had to look it up myself).> [PyPI]
His solution of maintaining separate code bases is … unusual. I feel like a cursory glance around the library landscape shows that most of the projects out there are maintaining a single codebase that supports 2.7+. six greatly simplifies most of this. I'm not aware of any projects that are supporting Python 2 and 3 concurrently by separating out their code completely.
> I presumed that I’d just open a “Migration from Python 2 to 3 Guide” and follow the instructions. Alas, there is no such guide. There appears to be no central resource whatsoever on the porting of code from version 2 to version 3.
An I'm Feeling Lucky search on that exact quote pulls up the migration guide in Python's official documentation.[1]
Re: Ride the carousel of folly with a Python migration
#6> The only somewhat problematic code was this: for line in iter( handle.stdout.readline, '' ): self.output.put( ( handle, line ) ) > This no longer terminated an emitted lots of odd values (one number repeatedly). It turns out it returns an empty b'' now when empty, as opposed to a ''. This could have been avoided had this API sensibly returned None instead of an empty string. For any observers, this is much more idi…
Re: Ride the carousel of folly with a Python migration
#7Sphinx is close to a standard nowadays.
Re: Ride the carousel of folly with a Python migration
#8"there is nothing in the PyPI package description that actually indicates what version of Python is being targeted"
is incorrect. There are Trove classifiers[1] for both versions, and indeed for every minor version number of both versions. There are even Python 2 and 3 classifiers that end in "Only", which look like they would exactly fit the author's use case.
Re: Ride the carousel of folly with a Python migration
#9I guess a masochist could do something like pipe 1 to 'patch -p0' or something…
I ran into the same unicode issues as the author, and dumped all the code that handled it because I didn't need it in 3.
I also reduced the whole codebase by some 150 lines because of not needing to do a bunch of extra work I originally designed in when working through the code. This was more due to fresh eyes.
ETA: the code was on 2.7 because a library I needed wasn't yet available under python 3 (FuelSDK from SalesForce) until November, and I completely missed this. 1.0 version supports py 3, but it wasn't in pip.
Re: Ride the carousel of folly with a Python migration
#10He claims there's no migration guide, but when I google on the phrase he used, "Migration from Python 2 to 3 Guide", or any variation of that phrase, the first hit is https://docs.python.org/3/howto/pyporting.html I wonder why he didn't find it.
I guess if everything went smoothly, he wouldn't have had a blog post to write.