Please port doconce so that it runs on python2.7 and python 3.4 both

[zaxebo1]

Many python libraries run on python 2.7 and python 3.4.
Especially one can use single file library of "six" ( see https://pypi.python.org/pypi/six ), which is compatibility library between python 2 and python 3). For example, mako templates runs upon starting from python 2.6 till python 3.4 - all simultaneously

So port doconce such that it runs on python 2.7 and python 3.4 both.

reference: my own comment on issue #25

[zaxebo1]

Believe, I am using reST and sphinx , just because doconce is python 2.7. I strongly believe that you will get more contributors and users , if it is running on python 3.4 and python 2.7 simultaneously.

if simultaneous support of py 2.7 and py 3.4 is not possible for doconce, then the time has probably come to switch to python 3.4 fully

[hplgit]

It is not entirely trivial as preprocess is not ported to Python 3, and this is an essential module. There might be more, but the process stopped already when importing preprocess.

However, I created a new branch, py3, and ran futurize stage1 and stage2 on the files. This automated procedure worked with very few manual adjustments. At least the files work under Python 2 (all tests pass) and compile under Python 3.

[zaxebo1]

If i port "preprocess" module such that it runs on python 3.4 and python 2.7 both; THEN will that encourage you to take up this python 3.4 porting of "doconce" in a prioritized defined time frame ??

In that case, i can take up the porting of "preprocess" such that it runs on python 3.4 and python 2.7 simultaneously ?

[hplgit]

Preprocess was easy to port, Publish a bit harder.

The process with doconce has stalled since with future (or six) \u is not tolerated in raw strings, see http://matplotlib.org/devel/portable_code.html. There are large portions of text generated with e.g. "\use..." for latex, and all backslashes seem to require a double . This makes long latex code hard to read and also maintain - and to port.

We need a smarter way of tackling \u in raw strings with future/six before proceeding.

[zaxebo1]

how does "sphinx backend for Latex" does it. Sphinx-latex backend must be dealing with the same task, the same approach may be relevant here too

[hplgit]

I have been looking more closely into these issues. The Sphinx authors seem to have manually translated the code to a common Python 2/3 version using a minimum of functionality from the six package. In that way, strings in Python 2 are str objects (byte strings) and file objects work with such strings.

The problem with doconce is that I used the futurize program to automatically create a common Python 2/3 code base. futurize applies from __future__ import unicode_literals, which ensures that all Python 2 strings are unicode strings. Any string with a backslash u will then essentially be ur'\u', which is illegal in Python 2, but works in Python 3. Dropping the automatic unicode conversion works fine until methods in file objects receive strings: those methods demand unicode strings. To summarize, futurize is constructed to force unicode strings in the common code.

There are three solutions. The first is to drop raw strings and use double backslashes. This requires quite some manual work and lower the readability of the latex translation substantially. A second solution is to replace \u by some other string and perform an inverse replacement at the end of the translation process. The downside of this approach is that much of the latex code looks ugly since \usepackage must be written \XUXsepackage or similar. The third solutions is to use str objects in Python 2 and 3 and thereby avoid unicode strings when the code is run under Python 2 (the Sphinx approach). This alternative will take a lot of manual work and probably be error prone (doconce has an order of magnitude more code in output languages in Python strings than Sphinx).

It would be good to switch to a common Python 2/3 code base now, but I have to think more about the \u issue and which solution that we can live with. Hopefully there is a better one...

[zaxebo1]

Though you have only \u issue left to think about, but still for the discussion-completion sake, i am posting here that for "all the other issues of python2 and python3 compatibility from the same code base" :-

additionally, probably these will link will be also of some use to you :

1. http://python-future.org/compatible_idioms.html ( <<== Very very important)
   http://python-future.org/

2. https://docs.python.org/2/library/2to3.html

3. http://pythonhosted.org/six/

4. http://python-modernize.readthedocs.org/en/latest/
   https://github.com/mitsuhiko/python-modernize

[hplgit]

Thanks, this is really helpful!

[dumblob]

@KGHustad does it work with Python 3 already?

[KGHustad]

Yes