What does HackerNews think of pyupgrade?

A tool (and pre-commit hook) to automatically upgrade syntax for newer versions of the language.

Language: Python

#61 in Python
That's a decade to make a 30 second change. Add something like https://github.com/asottile/pyupgrade to your pre-commit hooks and you won't even need 25 of those seconds.
Such goodness here and even points to an interesting project I’d never heard of for automated “de-deprecation”

https://github.com/asottile/pyupgrade

Howdy, author here. I'm particularly excited about Pants now supporting Pyupgrade: https://github.com/asottile/pyupgrade. It's a well-written tool to automate using all the amazing new Python features, like f-strings.

I'm happy to answer any questions and hear any feedback!

From my advice, try to stay on Python.

I am currently doing the opposite. Moving an old Java stack to Python/Django. Been able to do so under 9 months. I think upgrading to Python 3 should be doable. What's the version of your Django stack? You just need to try to reach Django 2.2. And if you are at Django 1.1, 90% of your code can be upgraded to Python 3. Nothing fancy. You just need to use libraries such as pyupgrade [0] to automatically upgrade your code, combined with black [1], flake [2],... Everything is done in less than 20 commits. From there you jump to 2.2 which supports Python 3.6+ .

It will be very difficult to implement all the goodies given by Django ORM/SQLAlchemy. But ... You if Java/C# is the tech that you feel confortable with, no problem. You have to use it. But, I really think it's easier to understand the "business domain" of Python code than Java/C#.

[0]: https://github.com/asottile/pyupgrade [1]: https://github.com/psf/black [2]: https://gitlab.com/pycqa/flake8

Unless the tool does something more than its tagline, pyupgrade[1] offers the same functionality and much more.

[1]: https://github.com/asottile/pyupgrade

You can start porting your live codebase to python 3 right now - no downtime at all. You can have a 2+3 compatible codebase live in a week or two, it'll get you about 98% the way there [1]

My projects (e.g. https://tmuxp.git-pull.com, https://unihan-etl.git-pull.com) are both python 2/3 compatible.

I learned by reading through other projects like Sphinx, Flask, Werkzeug, and SQLAlchemy:

- Flask: https://github.com/pallets/flask

- Werkzeug: https://github.com/pallets/werkzeug

- Sphinx https://github.com/sphinx-doc/sphinx/tree/v1.8.5 (see compat: https://github.com/sphinx-doc/sphinx/blob/v1.8.5/sphinx/util...)

- https://github.com/sqlalchemy/sqlalchemy

Helpful blog posts: http://lucumr.pocoo.org/2011/1/22/forwards-compatible-python..., http://lucumr.pocoo.org/2013/5/21/porting-to-python-3-redux/

As for automation tools, for 2/3 compatibility, I used futurize and huge codebase to great success: https://python-future.org/futurize.html. I started with this:

    futurize --write --stage1 --unicode-literals --nobackups 
and https://docs.python.org/2/library/2to3.html

    2to3-2.7 -w -n 
Really helped.

Also, wire Travis / your CI system to have your tests run on python 2 and 3.

If you want to test your python 3 codebase live on a subdomain / same SQL/NoSQL DB, be careful about jobs/tasks! Pickle version mismatches and stuff. Use a separate redis/whatever DB for the deployments.

After you're finally on python 3, you can use https://github.com/asottile/pyupgrade to modern your code.

[1] For the other 2%, use conditionals in your requirements file:

    enum34==1.0.4;python_version<"3"

    ushlex==0.99.1;python_version<"3"
> Git hooks with pre-commit

In projects where I am involved in, we usually set up hooks that run a few checks from https://github.com/pre-commit/pre-commit-hooks plus https://github.com/asottile/pyupgrade plus https://github.com/psf/black plus maybe the mypy and flake8 hooks. These hooks are also run in a "lint" stage by by tox, which is also run on the CI system. This catches some lints that slip through every now and then, before you go on to commit them. Also, a tox run will as a side effect also reformat the code before you check it in, which is a nice laziness feature.

I am currently thinking if I should move to the pytest plugins for mypy and flake8 because I find they make more sense as tests, especially if I'm developing inside a venv and repeatedly run pytest instead of tox. That would also mean that the mypy and flake8 checks are run repeatedly for every Python interpreter I want to tox, unkess I invest some time into coming up with better TOXENVs. Hm.