← Back to team overview

kicad-developers team mailing list archive

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