Re: NVDA 2018.3: wxPython 4 is not the same thing as Python 3


Several important reasons come to my mind:
* Python 2 sunset date is approaching: On January 1, 2020, support for Python 2 will be terminated by Python Software Foundation (PSF), the main entity that defines and coordinates development of Python programming language. Although there might be "night lighting" efforts - longer support by third parties, but for all intents and purposes, as far as CPython is concerned, that is the sunset date.
* Unicode: Python 2 had ability to deal with Unicode and older text encoding mechanisms. Python 3 standardizes this around Unicode. With more characters being added to Unicode standard (the latest edition, version 11.0, adds emoji and characters from additional scripts around the world), coupled with globalization and internationalization of software projects, it became important to standardize around this.
* New possibilities: Python 3 introduces features that could be used by NVDA and its add-ons, including asynchronous I/O, more predictable thread switching mechanism, virtual Python environments (for isolating code from the outside world for testing and other scenarios) and many others.
* Easier source code level debugging: if you run NVDA from source code, you'll find you're using Windows 8 when in fact you might be running 8.1 or 10. Python 3 adds native support for Windows 10, which makes it easier for developers to add new features or test bug fixes for Windows 8.1 and 10 as well as on older Windows versions.

Of course, with change comes responsibilities to make sure old code works as intended (as much as possible), and every change has its upsides and downsides. At the moment some NVDA developers (including I) are researching possible issues people will encounter when we do move to Python 3.

-----Original Message-----
From: <> On Behalf Of Don H
Sent: Sunday, August 26, 2018 11:39 AM
Subject: Re: [nvda] NVDA 2018.3: wxPython 4 is not the same thing as Python 3

So I have to ask the question why change to the new python if it has the potential of messing things up?

On 8/26/2018 1:14 PM, Joseph Lee wrote:

When I call espeak_Initialize when initializing Espeak from NVDA, I
get an exception and Espeak can’t find phonetics table from a specific
location. I will need to investigate this further, as being able to
get at least one synthesizer running in Python 3 mode is a crucial
milestone I hope to achieve soon.



*From:* <> *On Behalf Of *Reece
H. Dunn
*Sent:* Sunday, August 26, 2018 10:26 AM
*Subject:* Re: [nvda] NVDA 2018.3: wxPython 4 is not the same thing as
Python 3

On Sun, Aug 26, 2018 at 05:06 PM, Joseph Lee wrote:

Hi all,

For the last few hours, there has been a thread regarding
incompatibility of some add-ons and NVDA 2018.3, with some folks
claiming that speech synthesizers are not compatible. This
information is mostly false, and this may have been driven by
confusion regarding wxPython 4 versus Python 3.

wxPython: NVDA 2018.3 will upgrade wxPython GUI toolkit to version
4.0.3, a necessary milestone for the eventual migration to Python 3.
If an add-on uses attributes that are not found in newer wxPython
releases, they won’t load. Likewise, an add-on that exclusively uses
wxPython 4 material won’t work in older NVDA releases. At least some
GUI elements of speech synthesizer drivers are affected, and that’s
the reason why there has been an uproar regarding an important
add-on. Regarding speech synthesizer drivers and GUI issues, they
produce minor warnings, but apart from that, they are usable (but
not forever).

Python 3: Python is a programming language. Therefore, moving from
one version of a programming language to the next can be
challenging, especially if it introduces incompatible syntax and
throws away old internal assumptions. Python 2 to 3 migration will
go through both issues and much more, and research suggests that
many NVDA features and add-ons will be affected, including some
synthesizers the community uses (sorry, Espeak, you’re included in
this mix). Specifically, due to prevalence of Unicode, it’ll take
some time to come up with routines that will work with text
formatted as Unicode and other encodings, and unfortunately, some
speech synthesizers will insist on using ANSI format strings when in
fact Python 3 wants to read and write Unicode (Espeak is a notable

What is the issue/are the issues regarding espeak (I have experience
converting Python 2 to 3 code)?

Are you referring to espeak wanting UTF-8 (which is like/compatible
with ANSI/ASCII strings), or issues with the way the NVDA espeak
binding is written?

NOTE: UTF-8, UTF-16, and UTF-32 are all different Unicode encodings.
Espeak supports UTF-8 and UTF-16, but not UTF-32.

Kind regards,

In regards to add-ons, any add-on that deals with text processing
are affected (speech synthesizers, for example). Also, if they use
Python standard library (various Python modules), they need to take
note of differences between Python 2 and 3, especially in regards to
module and function renames (_winreg versus winreg, the former with
an underscore and the latter without).

A more general overview of what will it take to move NVDA to Python
3 can be found at:



Join to automatically receive all group messages.