pystache
pystache copied to clipboard
defunkt
Simultaneous Python 2 and Python 3 support.
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.
Usually py2 and py3 support is done like this: https://github.com/kennethreitz/requests/blob/master/requests/compat.py
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).
six is another approach to simultaneous 2 and 3 compatibility. I'm not sure what is so painful about running 2to3 though. That seems like an exaggeration. It's also taken care of automatically by setup.py.
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: 5e08418cb914e59f0c13e52323833ab0c06a4c9d
Thanks again for pointing that out.
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.