kicad-developers team mailing list archive
-
kicad-developers team
-
Mailing list archive
-
Message #08841
Python objects lifecycle
I've done the scripted plotting patch and it substantially
works-as-advertised; now I'll just have to port it to the main branch
(not a lot of work usually). I'd expect to have a public patch tonight.
During test I've noticed/tought about a couple of things, mostly due to
my ignorance about python innards:
- The plot controller objects keeps the plot file opened and close it
whenever a) the object is destroyed or b) another plotfile is opened
or c) you explicitly call the close method. At the moment I have to
use c) because the object isn't destroyed at the end of the script.
I assume it's because I store it in a global variable:
pctl = PLOT_CONTROLLER(GetBoard())
so since it remains reachable until pctl is in existance. I have no
idea about the python GC (reference counting? generational?
conservative? who knows...), so I have to assume that deletion is
'asynchronous and imprevedible' (as in most collected languages)
- More seriously, it doesn't like when object are deleted by C++ when he
already have a reference. Example:
brd = GetBoard() or whatever creates a BOARD proxy
then load or do a new board -> the BOARD is deleted and a new one
takes it place
Use brd from python -> hard crash since the memory was deleted
I know that in general this in not solvable (unless we hand over all
python-reachable object management to python; in lua for example this
is the way to do it...), but it is a serious problem to *at least*
think about.
- I've got a warning from the compilation of the swig wrapper saying
that (in short) the IO_ERROR and the PARSE_ERROR are catched in the
wrong order so that the IO_ERROR catch is executed for PARSE_ERROR
too; maybe it's harmless (I think it is, since the behaviour is the
same) but I don't like warnings (they are there for a reason...)
--
Lorenzo Marcantonio
Logos Srl
Follow ups