[PyQt] Writing dual python2/python3 code and the use of PyQt5.uic

[Eli Schwartz]

On 3/24/19 10:18 AM, Phil Thompson wrote:
> On 24 Mar 2019, at 1:59 pm, Eli Schwartz <eschwartz at archlinux.org> wrote:
>>
>> On 3/24/19 6:07 AM, Phil Thompson wrote:
>>> On 24 Mar 2019, at 1:48 am, Eli Schwartz <eschwartz at archlinux.org> wrote:
>>>>
>>>> I've been devoting some time recently to incrementally porting a PyQt5
>>>> application "calibre" (https://github.com/kovidgoyal/calibre/) from
>>>> python2 to polyglot code, hoping to get it running with python3 at some
>>>> point. One recent stumbling block I hit was that it uses the uic module
>>>> to compile forms into a cStringIO.StringIO.
>>>>
>>>> What I wanted to do was switch it to using the modern io interface, but
>>>> as it turns out, PyQt5 uses unqualified "str" instances to write out the
>>>> form. As a result, I cannot use io.StringIO on python2, and I cannot use
>>>> io.BytesIO on python3.
>>>>
>>>> The uic module quite specifically seems to expect that it will
>>>> manipulate unicode strings. I was able to get io.StringIO buffers to
>>>> work correctly with both python2 and python3 after I modified two files
>>>> to contain a "from __future__ import unicode_literals":
>>>>
>>>> /usr/lib/python2.7/site-packages/PyQt5/uic/__init__.py
>>>> /usr/lib/python2.7/site-packages/PyQt5/uic/Compiler/indenter.py
>>>>
>>>> Can this be added to at least these two files in the official
>>>> distribution? It seems to be a mistake that it ever assumed the str type.
>>>
>>> This...
>>>
>>> https://python-future.org/unicode_literals.html
>>>
>>> ...makes me nervous. I would prefer a more specific fix.
>>
>> The alternative is to add u'' decorations to the specific strings that
>> cannot be python2's dual purpose str/bytes.
>>
>> I *think* this should be sufficient:
>> https://github.com/eli-schwartz/pyqt5/commit/1a014130024530eb0241cec7ef7ffb82e2c69fc6
>>
>> patch:
>> https://github.com/eli-schwartz/pyqt5/commit/1a014130024530eb0241cec7ef7ffb82e2c69fc6.patch
>>
>> (Applied on top of a tarball import as I could not find any version
>> control sources for PyQt5.)
> 
> What about Python v3.3 and earlier?

python 3.3 was in security-fixes-only mode since March 2014, and it
finally reached End Of Life a year and a half ago, in September 2017.

IMO there is no reason to support EOL versions of python 3; everyone,
without exception, should be using newer versions of python 3. Even
python 3.4 is a big improvement on python 3.3, and that was EOL a few
days ago.

Either way, however, PEP 414 which added u'' strings back to python 3.x
was accepted for python 3.3, not 3.4, so it should work there too.

If a downstream project explicitly needs support for 3.2, which saw its
last source-only release in 2014 and was fully EOL in February 2016...
well, that is a very unfortunate development choice and I would strongly
urge such people to upgrade to a somewhat modern version of python (or
downgrade to 2.7 as that is still supported for another year).

Does PyQt5 have a policy for the minimum supported version of python 3?
Is it sufficient to only support versions of python that are still
supported by the Python Software Foundation?

The README specifies "2.6 or later", but it seems possible that the
README wording is simply unintended. If that means development must
remain compatible with 3.0 then that locks out a lot of options. And I'm
not even sure how much adoption python 3 actually had at that stage. o_O

-- 
Eli Schwartz
Arch Linux Bug Wrangler and Trusted User

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 1601 bytes
Desc: OpenPGP digital signature
URL: <https://www.riverbankcomputing.com/pipermail/pyqt/attachments/20190324/ba24fa6a/attachment.sig>