"start" parameter of PCell becomes restricted (in python) starting from KLayout >= 0.29.5

Hello KLayout developers! Not sure if I should classify this as a bug report, advice seeking or maybe a complaint :D, but thought this would be something good for KLayout devs to be aware of.

Following is strictly speaking about Python. In recent updates (>= 0.29.5) a function named start has become a member function of PCellDeclarationHelper. What this causes is that if a python class is declared that we want to register as a PCell, and it happens to have a parameter named "start", it will cause issues. Take this code excerpt:

import pya

class MyPCellClass(pya.PCellDeclarationHelper):
    LIBRARY_NAME = "Element Library"
    LIBRARY_DESCRIPTION = "Custom library of PCells"
    LIBRARY_PATH = "."
    def __init__(self):
        super().__init__()
        self.param("start", pya.PCellParameterDeclaration.TypeDouble, "A parameter of PCell", default=5.0)
    def build(self):
        # This doesn't seem to create any geometry, but whatever, the main point is that parameter name causes a crash
        self.cell.shapes(self.layout.layer("mylayer")).insert(pya.DBox(-5, -5, 5, 5))

library = pya.Library()
library.description = "Custom library of PCells"
library.layout().register_pcell("My PCell Class", MyPCellClass())
library.register("My library")

Here I have some simple class that I register as a PCell. (I place this script in the KLayout/python directory, but doesn't look like KLayout runs this on startup, so after launching KLayout I open a new layout, then use the macro development tool to run this script.)

Anyway, the "Custom library of PCells" library becomes selectable, and I see "My PCell Class" within it, but an attempt to drag-and-drop this PCell into the layout results with following:

Changing this parameter to some other unreserved name gets rid of this issue. So on our side we can deal with this issue, just rename the parameter and all references to it, "start" is probably not a good parameter name anyway. But this did take some time to debug, and it wasn't obvious what was causing crashes in our project. I was thinking if some strategy could be taken on KLayout's side to prevent namespace collision like this: maybe having a prefix with PCellDeclarationHelper member functions to decrease collision likelihood, or an assert when creating a parameter that tells that the name is reserved, or a mention in API docs that parameters can't share the name with member function (https://www.klayout.de/doc-qt5/code/class_PCellDeclaration.html doesn't mention start or finish for example).

I am interested to hear KLayout developers' thoughts on this. Thanks!
-Pavel

Comments

  • Hi Pavel,

    you're right. I'm sorry - I think I should have named the function "_start" (correspondingly there is "_finish").

    There are other reserved names, but they are not as generic (e.g. "produce"). I cannot change these, but I can change "start" and "finish" to hide the functions and make these names useful for parameter names again. I have created a ticket for this: https://github.com/KLayout/klayout/issues/1840

    In general, there is a low-level API to create PCells which is underneath the PCellDeclarationHelper class which is PCellDeclaration (https://www.klayout.de/doc-qt5/code/class_PCellDeclaration.html). It is possible to base a PCell implementation on that class without these side effects. The price to pay is a somewhat more clumsy interface - specifically, parameters are not handed over by name, but as a vector of values only.

    The introduction of "start" and "finish" is related to a request for supporting recursive PCell calls. It is discussed here: https://www.klayout.de/forum/discussion/2548. This discussion also explains how to use the low-level API which was the work around at this time and was supporting the recursive PCell application.

    Best regards,

    Matthias

  • Thanks for creating the ticket, no need to rush it on our account as it was an easy fix for us to change parameter name. Thank you also for additional context!

Sign In or Register to comment.