Ride the carousel of folly with a Python migration • Hacker News Board

Re: Ride the carousel of folly with a Python migration

#31

Post by di » Tue, Jan 24, 2017, 11:35 AM UTC

mortoray wrote: post #23

pdonis wrote: post #8

This 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?

You are correct, the classifiers are just search qualifiers.

However, since pip 9.0.0, it will respect the Requires-Python[0] metadata, which can be specified via your setup.py file.

Since PyPI allows only a single source distribution per release, though, this will still not get you separate modules for separate codebases as it seems you originally desired. As mentioned in a previous comment, it's generally preferred to support multiple versions in a single codebase via six.

[0]: https://www.python.org/dev/peps/pep-0345/#requires-python

Re: Ride the carousel of folly with a Python migration

#32

Post by slavik81 » Tue, Jan 24, 2017, 11:58 AM UTC

zzleeper wrote: post #30

slavik81 wrote: post #18

Earlier quoted context omitted.

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?

Interesting. I do stick to Python 2 features, but put in some work to ensure my programs are valid Python 3. I'm not a very skilled Python developer, so the simplicity of that strategy is attractive.

One thing that I notice is that your project is a library, while mine is a program. I wonder if that also plays a role.

Re: Ride the carousel of folly with a Python migration

#33

Post by dickbasedregex » Tue, Jan 24, 2017, 3:14 PM UTC

zzleeper wrote: post #13

In my opinion/experience, there are some important hidden costs of staying in py2: 1) Hard-to-read or quirky code. Unicode handling, args, harder unpacking, etc. The more time it passes, the more updates py3 gets, and the more outdated the py2 code looks. For instance, after a year almost exclusively in py3, I have completely forgotten about iter(), unicode gimmics, etc. and also rely more on stuff that is just too s…

>most people are now using py3

Citation? Still feels about 50/50 to me and even that number feels a little generous to Py3.

Re: Ride the carousel of folly with a Python migration

#34

Post by dr_zoidberg » Tue, Jan 24, 2017, 4:23 PM UTC

brianshaler wrote: post #17

dr_zoidberg wrote: post #16

Earlier 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.

Part of wanting no uncommited changes is to push a few issues that have been lingering around as "too easy, not important" and get the team to fix them once for all. But yeah, we could be a bit more "correct to the git way".

Re: Ride the carousel of folly with a Python migration

#35

Post by brianshaler » Tue, Jan 24, 2017, 4:27 PM UTC

throwanem wrote: post #29

brianshaler wrote: post #17

Earlier quoted context omitted.

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.

Yes, because they're pending changes. When they're finished, they can be committed and the branch can be rebased to include them.

Re: Ride the carousel of folly with a Python migration

#36

Post by throwanem » Tue, Jan 24, 2017, 5:14 PM UTC

brianshaler wrote: post #35

throwanem wrote: post #29

Earlier quoted context omitted.

That would prevent 2to3 from seeing them, though.

Yes, because they're pending changes. When they're finished, they can be committed and the branch can be rebased to include them.

At which point you need to run 2to3 again, and maybe update callers of the code you stashed, depending on what it actually does. If you know with certainty it isn't going to be affected in any way by the upgrade tool, of course, then either works as well. But otherwise I'd argue strongly for finishing the changes first, committing them, and only then running the upgrader.

It's an argument of preference in practice, and therefore all but guaranteed to go nowhere. I tend to think that updating a whole codebase like this is best done atomically rather than piecemeal, especially when the code belongs to a team rather than an individual. But I can see where opinions might differ on such a point.