Task: Update to latest (most appropriate) version of Python #12064
Comments
|
Fixed with PR Py3.8: Transparently use a Python virtual environment under the hood #12075 |
|
This was reverted by #12298 |
|
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.
|
|
Upgrading python in 2022.1 depends on the bug in |
Is there anything NV Access or the community could do to escalate this bug, or invest in fixing this ourselves? |
|
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.
|
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? |
|
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. |
|
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
|
|
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. |
|
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. |
|
I provided pr python/cpython#26204
Which is mentioned on that issue.
|
|
Hello. |
|
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.
|
|
How it will be to tr to update to latest version and try it firstly in the try build, to see was this fixed?
|
|
@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. |
feerrenrut
changed the title
|
Hi, September 2023 update: even though we have Python 3.11.x, I advise 3.12 (October 2023) as it is released after Windows 8.1's end of support and will allow us to update to binary releases until mid-2025 unless critical regressions with dependencies are found. Thanks. |
|
@josephsl Could you please clarify your point about Windows 8.1? Will Python 3.12 still support Windows 8.1 including Server 2012 R2? Server 2012 R2 will receive extended security updates until 13 okt 2026. |
|
Hi, we have a precedent: Python 3.9 dropped support for Windows 7 and Server 2008 R2 despite Microsoft providing extended security updates. Python Software Foundation follows Microsoft’s support policy for Windows releases support. Thanks.
|
|
I'm not strictly against it, but if we drop Windows 8.1 support as well, we really should consider our strategy regarding bitness of NVDA. In other words, I think there are hardly any x86 Windows 10+ users out there, and given several of our core dependencies are dropping X86 support for their wheels, a decision comes into view on this matter. |
|
Hi, According to docs, Python 3.12 supports Windows 8.1 and later. I expect 3.13 to be the first release to require Windows 10 unless Python core devs say otherwise. Given that NV Access is no longer working on Windows 8.x specific bug fixes, I think we might as well take this opportunity to move onto Windows 10 and later as part of Python upgrade. Thanks. |
|
It would be really great to have a clear statement from NV Access regarding what versions of Windows they intent to support with the Python upgrade, and if the migration to 64-bit is even something they consider for 2024.1. I am also curious what is the point of #15167 - as far as I can tell it merely duplicates content, and what we need is not a community discussion, but a clear announcement from NV Access. cc @seanbudd @michaelDCurran |
|
I believe the standpoint has always been that NVDA only drops support for particular Windows releases when the used techniques force us to. That's the reason why Windows 7 is supported until now, even though it has been deprecated for a long time now. SO if Python 3.12 supports Windows 8.1, there is no reason for NVDA not to. Re 64-bit NVDA, that will be a long journey. Quick research revealed that al ctypes calls involving pointer types would require explicit parameter annotations. ctypes seems to assume 4 bytes for a parameter by default, so throwing an 64 bit pointer at it will result in an OverflowError to be raised. It is probably way quicker to invest in custom wheel building when necessary for wxPython, for example. |
|
We'd like to update to python 3.11 as it is likely to be more stable/safer than 3.12 and we want to start work on updating python very soon. It should be easy enough to update to 3.12 in 2025.1 or later. We don't plan on fully dropping win 8.1 support, as python and windows still support it, even though we are no longer making bug fixes. Dropping 32bit support is not on the current roadmap as it is a massive rewrite.
Could you give some examples here? wxPython has fixed this for now at least: wxWidgets/Phoenix#2246 (comment) |
|
Hi, for Windows 8.x support, I think 8.1 or later is the way to go as 8.0 is no longer supported by Microsoft. Thanks.
|
I have missed that, I'm sorry. |
|
Do we have to keep using py2exe? Could migrate to pyinstaller?
|
|
I wasn't very happy with pyinstaller five years ago. See #8375 (comment) |
|
Interesting. I believe the library.zip issue is not a problem any more. The path
thing, though ...
|
|
What about Nuitka? It compiles to pyd and needs VS or another compiler though... |
|
I don't think switching away from py2exe is a serious point of discussion. |
In preparation for #12064 Summary of the issue: Certain types which are imported for type checking only are not correctly encapsulated by strings. threading.currentThread() is deprecated in favour of threading.current_thread() with Exception() as ex: syntax is no longer valid in 3.11 in wxPython 4.2.0, integers are expected for scaling sizes in wxPython 4.2.0, using AppendColumn is preferred with our current syntax of adding width Description of user facing changes None Description of development approach Makes various backwards compatible fixes that become compatibility issues when upgrading to python 3.11
Closes #12064 Closes #12551 Closes #15577 Closes #15167 Summary of the issue: Python needs to be updated to 3.11, as Python 3.7 is EOL. Python pip dependencies need to be updated to match the python upgrade. typing_extensions is no longer needed. Description of user facing changes Performance and security enhancements from dependency upgrades. Description of development approach Updates python in build scripts Updates pip dependencies Set Windows 8.1 (Blue) as minimum windows version Update references to python and windows version in docs nose is replaced by the unittest module with xmlrunner to generate XML test output drop python optimization to level 0 from level 1. level 1 removes asserts.
|
@LeonarddeR wrote:
While I cannot find it either, it would be good to create one with your initial thoughts. Even though there are no current plans to switch to 64-bit, we would certainly have to do so at some point, and having list of documented problems way in advance should be pretty helpful. |
|
Agreed, such an issue would be apreciated. |
Initially Python 3.8 was being considered. 3.8 was chosen because 3.9 drops support for Windows 7 (see discussion: #10933 (comment)). 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.
The text was updated successfully, but these errors were encountered: