Am 26.06.2019 um 12:40 schrieb Stephan Witt <st.w...@gmx.net>:
>
> Am 26.06.2019 um 10:46 schrieb José Abílio Matos <jama...@lyx.org>:
>>
>> 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
>
> Hi José,
>
> I’m not surprised at these explanation.
>
> The real world scenario would be to disable python 3.4 on my system
> and test it with 2.7.15 - this works for me.
>
> But - if it’s clear LyX doesn’t work with python 3.4 why is it tried and
> used?
> Or is it this what you propose? Change the tested minimal python version from
> 3.3.0 to 3.5.0?
> Then I’ll cannot agree more.The attached patch works for me on Mac. Stephan The terminal output is: $ /Users/stephan/git/lyx-build/LyX-2.4.0dev.app/Contents/MacOS/lyx -v Running: python3 -c 'from __future__ import print_function;import sys; print(sys.version_info[:2], end="")' sh: python3: command not found Looking for python 3.x ... Examining /opt/local/bin/python3.4 Running: /opt/local/bin/python3.4 -c 'from __future__ import print_function;import sys; print(sys.version_info[:2], end="")' Examining /opt/local/bin/python3.4-config Running: /opt/local/bin/python3.4-config -c 'from __future__ import print_function;import sys; print(sys.version_info[:2], end="")' Usage: /opt/local/bin/python3.4-config [--prefix|--exec-prefix|--includes|--libs|--cflags|--ldflags|--extension-suffix|--help|--abiflags|--configdir] Examining /opt/local/bin/python3.4m Running: /opt/local/bin/python3.4m -c 'from __future__ import print_function;import sys; print(sys.version_info[:2], end="")' Examining /opt/local/bin/python3.4m-config Running: /opt/local/bin/python3.4m-config -c 'from __future__ import print_function;import sys; print(sys.version_info[:2], end="")' Usage: /opt/local/bin/python3.4m-config [--prefix|--exec-prefix|--includes|--libs|--cflags|--ldflags|--extension-suffix|--help|--abiflags|--configdir] Examining /opt/local/bin/python3.6 Running: /opt/local/bin/python3.6 -c 'from __future__ import print_function;import sys; print(sys.version_info[:2], end="")' Found Python (3, 6) …
python-3-5.patch
Description: Binary data
