Hi,
i am trying to automatically extract parameters like PCB size, layers or structure size from .kicad_pcb files.
are there command line parameters that would allow me to do such a thing?
I’m looking for something like Targets -i (https://server.ibfriedrich.com/wiki/ibfwikien/index.php?title=Command_line).
If you use python
import pcbnew
will provide you some library to open the Pcb file and get this parameters.
Ok, that works.
for anyone who comes across this later:
pcbnew (at the moment of writing) is only compatible with python 2.7 and depends on some KiCAD dlls.
The easiest way to use it is to use the Interpreter that is shipped with KiCAD itself.
Only on Windows this is necessarily so (and even there unfortunately, for the reasons which don’t depend on KiCad developers). On other platforms KiCad may support python 3.
Why this shouldn’t depend on devs?
It is a limitation of the kicad winbuilder, not on the Win system… py2 is deployed/attached with kicad executables… it could be done in py3 but it will require some work on winbuilder.
so devs need to patch the wxPy… I remember that already someone had offered to patch it but he didn’t get much attention…
I simply think it is in a low priority level…
EDIT: and this is a bad decision imo, considering:
Might be even stronger than “recommend”. Some might even drop python2 altogether from their main distribution as unsupported packages pose a security risk. (There will for sure be some time period where py2 is still possible to be installed. Possibly via third party resources to avoid being made responsible for security updates.)
I find it mind boggingly incomprehensible that 10 years after the introduction of Python3 there are still discussion of anybody taking python 2 seriously.
I started writing in C about 30 years ago, and still happy with it, because of its universality and good fit for small uC’s. A few years ago I was interested in learning some easy to use script language for PC’s and tried python. I was so appaled by the incompatible python versions that I soon abandoned trying to learn python altogether.
Well C/C++ committee made the effort to ensure backwards compatibility in all language iterations. Python devs deliberately broke some things in version 3. So inevitably the community fractured because python 2 was widely adopted already and there was ton of production code written that was very hard to upgrade because of dependencies.
I would hope they learned their lesson but reading some dev mailing lists and noticing how boneheaded Guido can be, I would not be surprised if they step on those rakes again.
Sometimes the old standards fade to boat anchor and upheaval is inevitable. Yeah, there will be pain involved but what happens otherwise? It seems a new language pops into existence every day to address the boat anchors short comings. So which is more painful? Stagnating or changing? 
C++ seems to be handling it’s boat anchors just fine 
Sure, it takes time and 2 major versions to deprecate unwanted things but looking at python 3 adoption curve it took them the same 10 years to get ahead of python 2 so I call it a wash in terms of time and major PITA for devs.
But we are getting off topic.
I can comprehend that Python V2 had (has!) some mayor flaws that could not be remedied without breaking compatibility. But simply throwing Python 3 into the world as a separate entity is a very hobby level kind of immature thing.
Look at HTML, which has version info in it’s header. Look at C / C++, where C can be used inside C++ with “extern C”. Why would end users have to be bothered in which particular version of Python a script is written? Why is Python itself not smart enough to figure this out for itself? This is a very mayor oversight which has probably seriously delayed the acceptance of Python 3.
Just having “extern C” in C++ enables developers to port individual files, libraries, etc piece by piece from C to C++, and release intermediate versions, and do testing during the porting. The “all or nothing” switch has probably made many people stick to Python 2 and not even bother with V3.
I see your point but I do not think it is fair or captures the whole picture
Every single c and c++ compiler out there has incompatible extension and no major projects I can think of uses flags to enforce strict ANSI C or standard c++ leading to a proliferation of compiler locked code.
Additionally, ABI backward compatibility is a feature of Gcc/g++ only among major compilers, when using commercial compilers including vc++ the ABI is liable to break between releases, requiring recompiling everything if the compiler changes, all static libraries stop working or have subtle bugs (Proliferation of MsVC++ support packages for every year and release on any windows system)
Python has 2 major versions and libraries in each one are compatible in perpetuity without requiring recompilation.
Python 3 was not simply thrown in the world. Especially not recently. It is now > 10 years old and it was clear from the beginning that it will replace python 2 at some point in time.
And why is this a problem anyways? Well from the original release notes of python 3 https://docs.python.org/release/3.0.1/whatsnew/3.0.html
Python 3.0, also known as “Python 3000” or “Py3K”, is the first ever intentionally backwards incompatible Python release. There are more changes than in a typical release, and more that are important for all Python users. Nevertheless, after digesting the changes, you’ll find that Python really hasn’t changed all that much – by and large, we’re mostly fixing well-known annoyances and warts, and removing a lot of old cruft.
In programming it sometimes is a good idea to throw out legacy stuff that simply holds you back. In the long run such cleanups will pay off. They however add short term problems to users.
In the case of python there are ways around the problems via compatibility libraries like the future libs. There has been a very long time since python 2 was declared dead the first time. (It was always clear that python 2.7 will be the last python 2 release series. And the current date for end of life was known for more than 2 years. It also got moved back some time ago so it really is not anything anybody should be suprised by.)
And one of the major problems simply is that right now there is a mixture of both py2 and py3 out there depending on what system the user is running meaning we python programmers need to program for both. By finally killing py2 officially this will come to an end in the near future and will make programming in python much much easier.
This topic was automatically closed 90 days after the last reply. New replies are no longer allowed.