Task: Update to latest (most appropriate) version of Python

[feerrenrut]

• Update appveyor.yml
• Update to latest version of dependencies:
  • Scons
  • comtypes
  • wxPython
  • pySerial
  • py2exe
  • brltty

Initially Python 3.8 was being considered. 3.8 was chosen because 3.9 drops support for Windows 7 (see discussion: https://github.com/nvaccess/nvda/issues/10933#issuecomment-737709194). The plan was to upgrade to windows 3.8, give Windows 7 users early notice, then upgrade again a year later.

Instead, we ran into a bug in python which prevented updating: (see https://bugs.python.org/issue38748 and python/cpython#26204)

When this is resolved (at the next compat breaking release) we will update to the latest (most appropriate version of Python). If this is not fixed, we may have to consider moving NVDA to 64 bit, (the bug does not affect 64 bit python). This would be a large and risky change.

[feerrenrut]

Fixed with PR Py3.8: Transparently use a Python virtual environment under the hood #12075

[LeonarddeR]

This was reverted by #12298

[zstanecic]

Hi,

This was not reverted by 12298, but because of the libcfi issue i.e, not working of sapi4, and a bog in windows explorer in win 7 and windows server systems, respectively.

[feerrenrut]

Upgrading python in 2022.1 depends on the bug in libFFI being fixed, it isn't fixed yet, so I don't see much chance of this happening.

[LeonarddeR]

Upgrading python in 2022.1 depends on the bug in libFFI being fixed, it isn't fixed yet, so I don't see much chance of this happening.

Is there anything NV Access or the community could do to escalate this bug, or invest in fixing this ourselves? I noticed that the EOL date of Python 3.7 will be in 2023, so that gives us at least one extra year. However, it looks like this is a lang standing bug now and there isn't much demand for others for this to be fixed any time soon.

[josephsl]

Hi, I think it would be better to come up with our own alternatives and get a potential fix tested in the wild before trying to persuade libffi folks to take a look at our modifications. Thanks.

[lukaszgo1]

I noticed that the EOL date of Python 3.7 will be in 2023, so that gives us at least one extra year. However, it looks like this is a lang standing bug now and there isn't much demand for others for this to be fixed any time soon.

It is worth pointing out that new versions of Python 3.7 are no longer released as a binary copies therefore we are not keeping uptodate with them and are essentially stuck on 3.7.10 or whatever was the latest release provided as an installer. Has it been considered to compile Python ourselves to at least keep current with the security fixes?

[feerrenrut]

Note, in addition to raising the bug we have created an automated test in cPython to reproduce the issue. We can ask cPython / libFFI developers to look at it. Otherwise, we may have to take this one our self.

[zstanecic]

How come @lukaszgo1?

You have the people in the polish community, which still use sintalk at the daily basis, because they are used to it.

You have people who use Chinese VVtts, as a sapi4 component.

We are for the progress, and I am myself for the progress, but people will never change their habits when it comes to speech synthesizers, because some synthesizers are worse than others, just to mention vocalizer and cerence, which doesn’t listen users to fix the bugs.

Some people prefer still the robotic synths, or the synths like RHvoice, but who is going to take the project to make RHvoice to speak polish?

If you want to continue this discussion,

You can write to me privately in polish

[lukaszgo1]

I'm not sure I fully understood your last comment @zstanecic but in short what I've proposed above was to stay on Python 3.7 but use the latest releases by building them from sources since Python developers are no longer releasing binary versions of Py 3.7. Also it seems to me you're not realizing how serious the issue in libffi is - it affects much more than support for SAPI4 - there is no way to learn in advance in which cases NVDA would crash as a result of this bug.

[LeonarddeR]

According to https://bugs.python.org/issue38748 it looks like there's still a request open for a test to be provided using a pr.

[michaelDCurran]

I provided pr https://github.com/python/cpython/pull/26204

Which is mentioned on that issue.

[mzanm]

Hello. I think upgrading to python 3.8 in 2023 wouldn't make sense, because by then python 3.8 and even 3.9 would be considered old especially because they won't be getting any bug fixes, only security ones, so then we're back to the same issue.

[michaelDCurran]

The point is that we canot move off Python 3.7 before NVDA 2022.1 due to a stack corruption bug in Python.

Once this is addressed, we would move to what ever Python version seemed appropriate at the time.

[zstanecic]

How it will be to tr to update to latest version and try it firstly in the try build, to see was this fixed?

[feerrenrut]

@zstanecic We have added automated tests to python (see https://bugs.python.org/issue38748 and python/cpython#26204) which show the issue, the problem is still not fixed.

I'll update the title of this issue to clarify.

[josephsl]

Hi,

2022 update: has anyone tried Python 3.11 alpha and see if latest libffi fixes the issue discussed here? If yes, I think 3.11 would be the most appropriate version to upgrade to in fourth quarter of 2022 (October at the earliest).

Thanks.

[mzanm]

Honestly I feel like NVDA should really be 64 bit, Microsoft no longer offers 32 bit ISOs for Windows 11, and as seen here NVDA now is stuck on a soon to be unsupported version of Python because of that, on top of that you have the 64 bit adobe crashes and a lot of other issues.

[josephsl]

Hi, I think perhaps that might be the next thing to do after investigating Python upgrade. Note that this will require preparations to support 32-bit NVDA add-ons, most notably speech synthesizers – this is the reason for existence of NVDA Remote Loader executable to handle 64-bit apps in certain scenarios. Thanks.

[LeonarddeR]

The moment that Python 3.7 will be fully out of support is getting nearer and nearer. @feerrenrut could you please share NV Access' thoughts about this matter, especially given the Python team isn't paying any attention to this issue as it seems?

[josephsl]

Hi,

I might mention this in a new issue, but wxPython 4.2.0 does not come with Python 3.7 32-bit wheel - only 64-bit Windows and macOS builds are provided. This means we have to build that dependency ourselves via Appveyor (this takes time) or provide a wheel ourselves.

At this point, I think it would be much better to move to 64-bit provided that we are willing to come up with libraries to handle 32-bit x86, but we must also investigate ways to run x64 apps and libraries on Windows 10 on ARM64 (Windows 11 can be done easily thanks to x64EC). Bt if NVDA must stay as a 32-bit screen reader, then I think Python 3.11 would be a suitable candidate (meaning we must drop support for Windows 7 and 8.0; Python still supports Windows 8.1 for now).

Thanks.

[zstanecic]

What’s with the libffi issue and sapi4 corruption?

Note also that people still use old synths.

[LeonarddeR]

I might mention this in a new issue, but wxPython 4.2.0 does not come with Python 3.7 32-bit wheel - only 64-bit Windows and macOS builds are provided.

Are the wheels for Python 3.8+ X86 also missing?

But if NVDA must stay as a 32-bit screen reader, then I think Python 3.11 would be a suitable candidate (meaning we must drop support for Windows 7 and 8.0; Python still supports Windows 8.1 for now).

I guess it is just too early to drop X86 support altogether. Having said that, this decision can be based on the usage stats as long as the code in updateCheck is fixed to report ARM explicitly.

[josephsl]

Hi, yes, no x86 (win32) 32-bit wheel for wxPython (testing wxPy 4.2.0 at the moment, the biggest change being InitLocale function behavior, so I think it would be safe to work on 4.2.0 upgrade whenever NV Access is ready). Thanks.

[lukaszgo1]

I'm not sure how 3.11 can be considered suitable candidate given that the libffi bug still occurs with this version. If it were only affecting SAPI4 then we may certainly drop support for it and update, but it also causes crashes for UIA under various versions of Windows and possibly some as of yet unknown crashes which can only be found by extensive testing. As it stands I see 3 possibilities:

• Someone from NV Access or community or perhaps from Python fixes the bug for some future version of Python and we wait until that is done. Note that the EOL for Python 3.7 is not really relevant in our situation since we're stuck on the last binary release from August 2022 anyway, so we're already on an unsupported version for almost 2 years.
• Move to 64-bit - this requires a separate issue/discussion and frankly I'm not convinced this can be safely done in one release cycle.
• Move to 3.11 or whatever is the latest version rewriting known problematic components in C++ (for SAPI4 and UIA Handler this is perhaps manageable, but we still can experience some additional crashes after the release). Lack of WX Python wheels for x86 is not really a problem since we can easily compile it ourselves (I've tested that even for Python 3.7 this can be done, and while the build takes a long time if we would pre-compile it in advance that would not be noticeable).

As mentioned by Leonard it would be good to have a information about how many of our users are on 32-bit from someone at NV Access.

[zstanecic]

Well, 32 bit systems are one side of the medal, but what about the intercommunications between x86 apps on the 64 bit systems?

[lukaszgo1]

Well, 32 bit systems are one side of the medal, but what about the intercommunications between x86 apps on the 64 bit systems?

That's why I've mentioned that migration to X64 would probably require way longer than one release cycle.

[josephsl]

Hi, moving from 32-bit to 64-bit (even with hybrid architecture approach) will be a complex operation – way more than Project Threshold, I think (Python 2 to 3 transition took more than a year to get it right). We could move to 64-bit, but remember that 32-bit add-ons will need an additional layer to talk to 64-bit nvda.exe, and most are speech synthesizers. I imagine by the time Windows 10 leaves consumer support (late 2025), 32-bit will be close to a thing of the past (there are folks still using 32-bit systems). Thanks.

[michaelDCurran]

Just answering the question about 32 bit daily usage: It is now just on 5%. 95% are 64 bit.

[feerrenrut]

The moment that Python 3.7 will be fully out of support is getting nearer and nearer. @feerrenrut could you please share NV Access' thoughts about this matter, especially given the Python team isn't paying any attention to this issue as it seems?

@leonardder We don't have a detailed plan for the upgrade to 64 bit python yet. We do have a few ideas for approaches we might take:

• Upgrading Python to a recent version will require dropping support for Windows 7. I suspect many of the users who are on a 32bit OS are on Windows 7.
• The quickest / smallest effort approach will be to drop support for 32 bit add-ons, this is probably our preferred approach at this stage. However, we will engage in community consultations before embarking down this path.
• Alternatives:
  • Fork libffi / Python, fix the issue and build it for use with NVDA. This likely has a high maintenance cost.
  • Upgrade to 64-bit python and build a 32-bit bridge for older add-ons. This will be a lot of work, and highly experimental.
  • Fix the issue in libffi directly, and petition the python devs to include it in the next python update.