Subclassing the Cell() Class

Hi All,
I am writing some functions which extend the Cell class in the klayout.db Python module. With the Layout class, I can do the following:

class ExtLayout(kl.Layout):
    """Primitives for layout, based on KLayout database."""

    def __init__(self, technology, working_directory=None, layout_directory=None):
        """Initializes a new layout."""

        # Initialize the kl Layout object
        super().__init__(self)

        if working_directory is None:
            self.working_directory = os.path.join(os.getenv('pcp'), 'working_directory', technology.name)
        else:
            self.working_directory = working_directory
            ......

and it works as expected, but I can't do that with the Cell class. I think this is because the only way to initialize it is via the Layout object:

lay = Layout()
cell_obj = lay.create_cell('name')

So I didn't find a good way to write an __init__ function for an extended cell class. Do you have any suggestions? (one could write a more complete __init__ class for Cell which has a layout object as an argument, so the cell is placed in a layout).

So what I want to do is to add some new methods and attributes to the Layout() and Cell() classes which works in the Layout() class but not the Cell() class.

By the way, the new klayout.db module works incredibly well with PyCharm !!

Thanks in advance,

Erwin

Comments

  • Hi Erwin,

    thanks for trying the new Python module - I hope we can release that soon in some official release.

    Regarding your question: unfortunately, currently there is no way to subclass the internal objects of KLayout. Actually, there is no real Python object representing a cell. The Cell object lives inside C++ and the Python object technically is just a proxy to this object. Hence you cannot assign a particular class to such a Cell object.

    For some objects, ownership transfer happens and these objects remember their Python (or Ruby) identity while they are bound inside C++. But this comes with a considerable overhead - for example for virtual function overloading, so this effort is spent usually only on objects where Python specialization is vital. For example, the PCellDeclaration objects are equipped with this ability to allow specialization for a particular PCell.

    Kind regards,

    Matthias

  • Hi Matthias, thanks for the explanation, this is what I thought. I of course have a workaround, by creating an instance of the KLayout cell and call that one rather than using inheritance.
    Best regards, Erwin

  • You could of course overload every cell constructor in db.Layout and call your cell initializer, if that’s a functionality that you want. If there’s a unique use case for these, we can include this functionality in the python package. That’s why right now klayout.db is an empty module that redirects everything to klayout._db, which is the C++ module. Can you explain your use case?
Sign In or Register to comment.