Did you read the link I gave above ?
That suggests you can actually satisfy both branches and encourages development that is portable.
To assist that approach, it seems kicad could offer an installed choice of both Py2.7 and Py3 consoles.The porting effort multiply effect here is on the user side, not Kicad development.
Companies expect their scripts to continue to work.
I did read it. It sounds good and that would support people with already written modules. I still think that KiCad is in enough flux, that if there was a time to break cleanly the sooner the better, hence my support for just moving to 3. But if it is as easy as the porting link suggests then maybe the developers could follow that instead.
Does anyone have a clear picture of how much? And how much is public/open-source and how much is purely internal?
Python 2 is not being actively developed after 2020, and at least on the open-source a community effort could be organized to port it.
The python 2 official retirement isn’t the most crucial date to KiCad. Even now, the thing which has been problematic and lead to the planned 5.1 release is support for python libraries on Linux distros (specifically wxWidgets support). In the future the adoption of python 3 and abandoning of python 2 in the last distros are the watershed. Usually Debian stable is the last one in everything, unless it is luckily released in a good moment.
I don’t think there’s need to change the programming language. If something would be added, it should probably be javascript. I’m sorry, the fans of more rare languages, but generally speaking (outside KiCad) when a programming language is chosen, other than technical merits may be more important. Existing user base and willingness of people to learn the language are some of the most important criteria. See for example the results of the search “most popular programming languages 2018”:
https://spectrum.ieee.org/static/interactive-the-top-programming-languages-2018
https://www.tiobe.com/tiobe-index/
A quick scan of one directory here shows 122 .py files, and I’m a fairly low-use case. So kicad focused Python will easily run into many tens of thousands out there, a small portion of which will be open source.
I don’t really care about “actively developed”, I just expect my scripts to continue to work.
That’s the litmus test most PCB designer would use.
In all other software I have, source code continues to compile fine on the compilers it is designed for, so the 2020 is more of a token date, than any genuine expiry.
Of course, if KiCad offered two Python consoles, I could test any scripts, as time allows, in both versions.
I get your point – with Python 2.7 seizing development it will in a sense become more stable than anything else 
. I think API changes in KiCad might be just as big risk as a 2 -> 3 switch.
Do you know if any applications which have two Python versions as part of the execution environment? I can’t really think of anything which would hinder it per say, since pipenv etc already enable such behavior.
I started with a python3 port: https://github.com/pointhi/kicad-source-mirror/tree/python3
For now it is only able to build and link to python3. Actually executing something results in the following error:
Python 3.6.6 (default, Jun 27 2018, 13:11:40)
[GCC 8.1.1 20180531] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> import pcbnew
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
File "/usr/lib/python3.6/site-packages/pcbnew.py", line 38, in <module>
import _pcbnew
ImportError: /usr/lib/python3.6/site-packages/_pcbnew.so: undefined symbol: init_pcbnew
But I suspect getting python 3 working should be not to much hassle. At least SWIG supports both.
About getting python 2+3 support: I’m not familiar with c extensions as well as python scripting inside of a c++ application. But from which I saw, I would assume the following:
Note Python 2.7 is going to be unmaintained… thats very different from frozen/maintenance mode. So, thinking that it’s going to remain rock solid is probably a false hope.
Expect libraries to stop supporting 2.7 etc… and bugs won’t be fixed as other libraries around python 2.7 in the environment and OS move on.
Probably still worth supporting for while but people should know by know as they’ve had years and years of warnings that it is going away.
Funny to see this debate happening here now… in most communities it happened 5+ years ago.
Py3 is no longer the future, it’s the present.
The arguments about maintainance/porting are tired, and especially pathetic when you’re talking about the kinds of tiny scripts kicad users are writing.
Well it sounds like there are some people out there with larger scripts in KiCad… but yeah.
If the API is going to break between now and the new stable API perhaps it may as well be a clean break heh…
I can see Python 2 getting dropped by Ubuntu/Debian by about 19.04
Wow, that’s based on Debian hasn’t even made a decision on dropping support for Python2? Ubuntu is doing their own job on this.
Short status update:
My takeaway from the article :
Debian has made the decision to ship Python 2 with Debian 10 (“buster”), which will be released in mid-2019; that means Python 2 will be supported in Debian well past its 2020 end of life. For Ubuntu, the plan for the 20.04 LTS release has Python 2 removed from the main repository. That means it will not be supported by Canonical, so the community will need to pick it up if it is to continue at that point.
Historically, KiCad devs would wait until KiCad no longer builds on several platforms before updating a dependency, I think we can see with gtk3 this causes a somewhat painful experience. The trade off is causing users a lot of upgrading work.
So there is a non-obvious “right time” to move to Py3, my gut tells me between now and v6 release is the time. It might be nice if KiCad was ahead of the curve on this one, even though I am loathe to rewrite a lot of scripts for Py3, it has to be done sometime.
A clear heads up for users is needed, KiCad should announce that v6 will have Py3 support and you have all got 2+ years to get ready. Nightlies post 5.1 should have Py3 enabled by default.
This is great
It’s important to get real information on what works, and what does not, and to confirm what is possible.
Can you expand on what
I already ported some scripts and they are all working.
vs
Scripting inside of KiCad was not tested yet.
means ?
Does the first one mean you can access Pcbnew database from Python3, (via import pcbnew ?), or something else ?
For the scripts that are working, can you broadly list what they do/use, perhaps in a ‘tested so far’ read me portion on github ?
Clearly Linux is not going to be a problem except for wxPython.
As Wayne points out on Launchpad, Windows and mingw32/64 is the challenge.
FWIW, I started to port my personal scripts (not KiCAD related) to py3 a year ago and should have converted all systems I administer to py3 within another 12 months.
Ok, In more details what I have tested/ported so far successfully:
What is not tested/ported:
If anyone wants to try the python3 branch add -DKICAD_SCRIPTING_PYTHON3=ON to the cmake flags.