Bear in mind that most action plugins are tested only with python2. Though I would not mind to if somebody would test them and report bugs.
It would be good to drop 2.7.
It will be EOL during the 5.1.x active life cycle https://pythonclock.org/
2 Likes
There are good heavy reasons to drop it for 6.0 but practical, technical, forcing reasons to keep it for 5.1. I believe everyone hopes the circumstances will be different when 6.0 is ready to come out and every package/platform can enable python 3 and that it will be the default configuration option. The situation where it can be either one is unbearable for plugin developers/users. I wouldn’t want to spend any time learning how to support both in a script. There are enough burdens already for plugin developers/users.
1 Like
Here’s Wayne’s explanation for why python 2 is used on Windows:
You should ask the package maintainers of other platforms why python3/wxWidgets+GTK3 isn’t there.
1 Like
Yea but that should only effect microsoft builds. Why would it affect ubuntu (or any other of the sane platforms)?
Is this only a problem under the old 16.04 and we should point users to 18.04? (18.04 has python 3 as the official default and they seem to indicate that one needs special permission to get included if one uses python 2. Which is understandable as they might be worried about the security implications of including a package that will not be supported till the end of the lifetime of this release.)
2 Likes
I’m also waiting for the day Python 2 is finally obsoleted.
At the moment I’m still working with KiCad V5.0.2 on Debian Buster and do not have much in the area of scripting in KiCad. Only the Footprint Wizards work.
Here’s another website trying to make a statement to obsolete Python 2.
https://python3statement.org/
The Python website itself does not seem to be much concerned about motivating projects to (finally) switch to 3. At https://www.python.org/ I could not easily find any statement about obsolescence of Pyhon 2 and I’m afraid it will still be years before we finally get rid of it.
2 Likes
It will not be maintained past Jan 2020.
Which doesn’t mean it will immediately disappear in all distributions, of course. So yes, it will be here for years until we can get rid of it but nobody should be writing new software targeting python 2 if at all possible.
I agree that for KiCad 5.1 makes sense to stick to python2 because at the moment python3 dependencies are not available on all platforms. And plugin writers should update their scripts to be python3 compatible in preparation for v6 when it will be (hopefully) default. It’s not that hard.
1 Like
I had no doubts that there would be an end of life statement on python.org somewhere, but the pointI was trying to make is that you have to go searching for it. It’s one of the disadvantages of open source software. The old stuff never goes away.
It seems that attempts to make people more aware of this deserves a more prominent place on the Python website.
When I now start python from the command line it still defaults to 2, and in the credits there is also no mention of it’s near end of life.
paul@dualcore:~$ python
Python 2.7.16rc1 (default, Feb 18 2019, 11:05:09)
[GCC 8.2.0] on linux2
Type “help”, “copyright”, “credits” or “license” for more information.
. >>>
co-existance of 2 incompatible python versions for 10 years is so mind boggling silly to me that I could not even take the whole language seriously and did not bother to learn it.
1 Like
And a few extra characters
1 Like
There is a long list of Python software on that site that is committed to stopping 2.7 support. This includes well known projects like NumPy, Matplotlib, Cython
1 Like
Until/unless the list of projects committed to switching to 3.0 includes the projects that KiCad depends on, we are stuck with supporting 2.7. The alternative is removing scripting from Windows builds.
That said, individual packagers may choose to move to Python 3.0 for their supported systems. I think the Rawhide build and the Debian Sid build are there already.
According to Wayne issue is wxPhoenix not building under msys2. Is that the only thing stopping python3 on win? It may be possible to add a patch that can be incorporated in winbuilder.
This is the reasons I still have my python code stay away from wx and python 3 
That would be excellent. I think that is the only missing dependency. As we haven’t had a successful build yet, there may be lurking issues behind that as well.
2 Likes
I maintain kicad in openSUSE and we are actively trying to shift to python3 but alas python-wxWidgets still only works with python2
1 Like
If you use wxpython 4 aka phoenix, you can enable python3.
Yeah, go ahead an make a PR on https://github.com/msys2/MINGW-packages/blob/master/mingw-w64-wxPython/PKGBUILD
1 Like
I have not yet used Python scripts yet because of the wx and GTK problems with linux, but recently I switched to KiCad V5.1 and it claims to have scripting support according to the version info.
Scripting does not work (yet) however.
I think that with scripting you should have an extra icon on the left between “Hide board ratsnest” and “Show filled areas in zones”.
I do have a:
Pcbnew / Tools / Scripting console
(And an icon for it on the top of the screen), but when I try to start it, it barks at me with:
Debian Buster got frozen on KiCad V5.0.2. KiCad V5.1 was installed by temporarily setting the repositories to “unstable” and then installing KiCad, and after that setting the repositories back to buster.
Application: pcbnew
Version: 5.1.0+dfsg1-1, release build
Libraries:
wxWidgets 3.0.4
libcurl/7.64.0 OpenSSL/1.1.1b zlib/1.2.11 libidn2/2.0.5 libpsl/0.20.2 (+libidn2/2.0.5) libssh2/1.8.0 nghttp2/1.36.0 librtmp/2.3
Platform: Linux 4.19.0-4-amd64 x86_64, 64 bit, Little endian, wxGTK
Build Info:
wxWidgets: 3.0.4 (wchar_t,wx containers,compatible with 2.8) GTK+ 3.24
Boost: 1.67.0
OpenCASCADE Community Edition: 6.9.1
Curl: 7.64.0
Compiler: Clang 7.0.1 with C++ ABI 1002Build settings:
USE_WX_GRAPHICS_CONTEXT=OFF
USE_WX_OVERLAY=ON
KICAD_SCRIPTING=ON
KICAD_SCRIPTING_MODULES=ON
KICAD_SCRIPTING_PYTHON3=ON
KICAD_SCRIPTING_WXPYTHON=ON
KICAD_SCRIPTING_WXPYTHON_PHOENIX=ON
KICAD_SCRIPTING_ACTION_MENU=ON
BUILD_GITHUB_PLUGIN=ON
KICAD_USE_OCE=ON
KICAD_USE_OCC=OFF
KICAD_SPICE=ON
Maybe you don’t have all the required packages installed because of the repo hack?
I guess it may be helpful if you dump a list of all your kicad packages and their versions. Then maybe @tijuca will be able to spot the issue.
Fedora trying to eliminate packages depending on Python 2 for F31:
https://fedoraproject.org/wiki/Changes/F31_Mass_Python_2_Package_Removal
This topic was automatically closed 90 days after the last reply. New replies are no longer allowed.