use pasteurize in setuptools, similarly to use_2to3

[anntzer]

Would there be a way to use pasteurize in setuptools similarly to use_2to3? i.e., only commit Py3 code, but have a setup.py that contains something like

setup(..., use_pasteurize=True)

and have the code be pasteurized when installing (and testing) on Py2.

The idea is that pasteurized code can look quite "ugly" (e.g. keyword only arguments), so I'd rather not keep it committed, but with a good test suite, I can still make sure that the pasteurized version always works on Py2.

[Uzume]

I agree. I believe the main tenant of the python-future project is to be able to maintain a single portable code-base that can be executed on both Python 2 and 3 but unlike some earlier attempts focuses on making Python 3 idioms and constructs executable on Python 2 (as much as possible) vs. the reverse and/or some strange middle ground. This makes very good sense as many of the breaking changes in Python 3 are intentional in order to fix and/or remove perceived broken misfeatures that crept into the language over time (i.e., continued use of such should be discouraged).

setuptools does have a use_2to3 build process parameter but discourages its usage and I believe rightly so because it does not seem particularly useful to maintain Python 2 code that can be machine modified to run on Python 3 when the opposite seems to much more forward thinking and useful.

I would prefer to maintain a clean Python 3 code-base that can be pasteurized to run on Python 2 than maintaining an uglier futurized Python 3 code-base with much extraneous compatibility code (even if such is benign on Python 3).

The way I see it there are three options to maintaining a single compatible code-base:

1. machine portable Python 2 code (e.g., futurizable code)
2. portable Python 2/3 code (e.g., futurized/pasteurized)
3. machine portable Python 3 code (e.g., pasteurizable code)

It seems to me the python-future project currently recommends option two (based on the website Quickstart guide, etc.) but frankly I see that as the least desirable option (even when such is more Python 3ish than Python 2ish). I agree with @anntzer that the most desirable option is three in conjunction with a good test suite (that like the rest of the code should be executable on both Python 2 and Python 3: the platforms one wants to support).