That doesn't sound so bad. When I ported a medium sized system to Python 3 two years ago, I found serious bugs in four library packages. It took me about a month to get everything working. He's not reporting anything like that.
Ride the carousel of folly with a Python migration
21–30 of 36 posts
Re: Ride the carousel of folly with a Python migration
#22He 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.
That is not an actual migration guide. It's merely a meta-doc saying what types of things you need to pay attention to. I was looking for a specific list of things that would have to be migrated. The docs mention of reading the release notes for each versino of Python 3 isn't very helpful.
Re: Ride the carousel of folly with a Python migration
#23This statement in the article... "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. [1] https://pypi.python…
Okay, they are classified but I don't see that anything in the setup, or pip package management, seem to actually use them. Are they somehow used in actual package management, or just search qualifiers?
Re: Ride the carousel of folly with a Python migration
#24Earlier quoted context omitted.
In addition to what you've pointed out, he claims that 2to3 didn't do anything to his code, and yet he had to fix print statements. 2to3 definitely fixes print statements; he likely didn't read the usage or docs at all. By default it prints a diff, you have to use 2to3 -w if you want it to modify files on disk -- I certainly don't want tools modifying files in-place by default, so that seems like the right API to me.
The simple syntax changes I did prior to running 2to3 as they came up on the first run I tried. The semantic changes that didn't come up in 2to3 is what I was more bothered about.
Then you should update your post to say that, rather than saying 2to3 didn't do anything to your code.
Re: Ride the carousel of folly with a Python migration
#25> 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…
The `iter` form of the `readline` doesn't load the entire stream first, whereas the second form you posted does. This makes a significant difference when reading data from another program. I saw that migration guide, but it has very few details about what is actually involved in migration. It doesn't include API change details.
Why do you think the `for` loop form loads the whole stream? That shouldn't be true, since `for` just calls `iter` on the object internally, and normal file-like objects by default are iterated line-by-line.
If you saw the migration guide but found it incomplete, you should edit your post to say that rather than saying there isn't one.
Re: Ride the carousel of folly with a Python migration
#26Earlier quoted context omitted.
In addition to what you've pointed out, he claims that 2to3 didn't do anything to his code, and yet he had to fix print statements. 2to3 definitely fixes print statements; he likely didn't read the usage or docs at all. By default it prints a diff, you have to use 2to3 -w if you want it to modify files on disk -- I certainly don't want tools modifying files in-place by default, so that seems like the right API to me.
The simple syntax changes I did prior to running 2to3 as they came up on the first run I tried. The semantic changes that didn't come up in 2to3 is what I was more bothered about.
Try using some of the 2to3 fixers https://docs.python.org/2/library/2to3.html#fixers like the idioms fixer.
Re: Ride the carousel of folly with a Python migration
#27Author, please stop responding to every negative comment. That looks pretty pathetic, especially when you just expose your lack of expertise this way.
Re: Ride the carousel of folly with a Python migration
#28> 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…
The `iter` form of the `readline` doesn't load the entire stream first, whereas the second form you posted does. This makes a significant difference when reading data from another program. I saw that migration guide, but it has very few details about what is actually involved in migration. It doesn't include API change details.
I'm sorry but that is fundamentally incorrect (and shows a big knowledge gap).
Interesting article though, thank you for posting it.
Re: Ride the carousel of folly with a Python migration
#29Earlier quoted context omitted.
> By default it prints a diff, you have to use 2to3 -w if you want it to modify files on disk -- I certainly don't want tools modifying files in-place by default, so that seems like the right API to me. Well, running 2to3.py -w -n -o [new_py3_path] [old_py2_path] got me a copy of a project with every fix already applied. Another alternative I've been thinking is doing a "last before 2to3 commit" (and leaving no pendi…
You could also test the waters with a `2to3` branch. If you have uncommitted changes, instead of dropping them in as "last before..." you can git-stash them before branching and git-stash-pop them when you come back.
That would prevent 2to3 from seeing them, though.
Re: Ride the carousel of folly with a Python migration
#30Earlier quoted context omitted.
About PyPI, it is a bit messy. I backported a py3 project to use py2 (on behalf of a few users) and it was a real pain in the ass to have a wheel that allowed for both versions. I ended up having a py3 build on github, and using a TravisCI build that ran pasteurize and pushed to PyPI that version. At this point, I don't even know what the travis.yml file is doing (100 lines), and regret a bit backporting the project.
What makes it difficult? My projects are all quite simple, but I do keep them compatible with both Python 2 and Python 3. All I had to do was create a setup.cfg that said: [wheel] universal = 1 To build, I use: python setup.py sdist bdist_wheel twine upload -s dist/* The .travis.yml is just 7 lines. https://github.com/cgmb/guardonce/blob/v2.0.0/.travis.yml
Are you using py3 exclusive features? If you are not, then you are not really using python 3 (tuple unpacking, etc.)
If you want to do both, then you need pasteurize, and end up with a travis mess: https://github.com/sergiocorreia/panflute/blob/master/.travi...
To be honest, for me the morale of the story is that supporting py2 is just not worth it. I am not going to use it, so why support it at all?