-
Notifications
You must be signed in to change notification settings - Fork 309
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Simultaneous Python 2 and Python 3 support. #169
base: master
Are you sure you want to change the base?
Conversation
$ 2to3 -x unicode -x basestring --write --nobackups --no-diffs --doctests_only pystache $ 2to3 -x unicode -x basestring --write --nobackups --no-diffs pystache
Usually py2 and py3 support is done like this: Wouldn't be too hard to do for pystache. |
If we are interested in moving forward with this and format is the only thing holding back, I would be happy to move my patch into the compat.py format. Travis CI is failing primarily because 2.5 is no longer supported. I am unsure if this code functions under 2.4 or 2.5 as stated in the documentation. http://blog.travis-ci.com/2013-11-18-upcoming-build-environment-updates/ |
The code does work with 2.4 and 2.5 (at least as of version 0.5.3), but we can no longer test that with Travis CI. See also issue #137 (which should probably also list Python 2.5).
|
I apologize, that must have come across badly. My pain point has little to do with 2to3 and the work you put into it (see 5adbcd9), but instead with deploying separate packages for Python 2 and Python 3 to my non-traditional architecture which can't include setuptools. I'm not going to be offended if you don't want to merge this patch. It was just something I needed and I wanted to share back. |
FYI, I removed Python 2.5 from the Travis config: 5e08418 Thanks again for pointing that out. |
Is this PR still needed? |
I personally don't need this anymore. I ended up co-authoring (some pairing and speed fixes) noahmorrison/chevron. Also, since then I have left the company with this requirement, and they may have fully converted to python3 anyway. That being said, I'm personally of the opinion to provide backwards compatibility to python2 through writing compatible code, rather than forwards compatibility using the converter. |
In one of my projects I have a need to deploy to both Python 2 and Python 3 targets, making the 2to3 conversion solution rather painful. Would there be any objections to creating a polyfill (backfill?) for Python 2 for unicode or something similar?
I couldn't find the full reasoning when this was discussed previously. Thanks for bearing with me.