On Tuesday, 25 June 2019 19.17.13 WEST Stephan Witt wrote:
> +checking list of modules...
> /Users/stephan/git/lyx-build/LyX-2.4.0dev.app/Contents/Resources/layouts/fix
> me.module Traceback (most recent call last):
>   File
> "/Users/stephan/git/lyx-build/LyX-2.4.0dev.app/Contents/Resources/configure
> .py", line 1875, in <module> checkModulesConfig()
>   File
> "/Users/stephan/git/lyx-build/LyX-2.4.0dev.app/Contents/Resources/configure
> .py", line 1495, in checkModulesConfig retval = processModuleFile(file,
> filename.encode('ascii'), bool_docbook) File
> "/Users/stephan/git/lyx-build/LyX-2.4.0dev.app/Contents/Resources/configure
> .py", line 1594, in processModuleFile % (modname, filename, desc, pkgs, req,
> excl, catgy, local))
> TypeError: unsupported operand type(s) for %: 'bytes' and 'tuple'
> 
> Best regards,
> Stephan

Thank you Stefan,
        these results make all the sense to me.

This problem only occurs in python 3.4, it works for 3.5+.

TLDR; I honestly suggest that the minimum python 3 version supported to be 
python 3.5.


The long explanation:

For those that have been following the threads regarding python 3 and LyX the 
main topic is always the same.

When python 3 was released in 2008 (really!) there was a wish to drop some 
features and to fix long standing design decisions on python.

It worked is most cases. But in some cases those changes went too far, and 
thus all the issues regarding the transition from python 2 to python 3.

At some point, if you remember I said that in a sense python 2 and python 3 
were different languages. And I maintain what I said at that time.

One motto of python (for versions 2 and 3) though is:

$ python3 -m this | grep purity
Although practicality beats purity.

$ python2 -m this | grep purity
Although practicality beats purity.

So the practical side won and the successive python 3 versions brought more 
and more features to support the python 2 transition.

The last part of these came with python 3.5, and in one cases is related with 
the interpolation of byte strings. The feature that works similarly to fprintf 
and friends in C/C++.

The % operator, used to work only on strings (that have a defined encoding) 
and not in sequence of bytes. That decision was by design. The main issue is 
that sometimes we are working on text files for which we do not know the 
encoding but we know that they have ascii.

This applies a lot to lyx files before 1.6, but not only.

After too many complains the decision was reverted in python 3.5. That allows 
for the same code to run in both python 2 (that does not distinguishes between 
strings and sequences of bytes) and in python 3.

In this particular case we can track all the cases where this feature is used 
and ensure that the alternative works for both python 2(.7) and for python 3.

My suggestion as in other messages this year is simply to bump the requirement 
to python 3.5 and live with it.

Best regards,

PS: the above is technically correct but you should take the philosophical/
technical considerations with a grain of salt. After all the language name 
comes from the "Monty Python Flying Circus" and no one is expecting the 
Spanish Inquisition. :-) :-D

-- 
José Abílio


Reply via email to