Attention is currently required from: dexter, fixeria, neels. laforge has posted comments on this change by neels. ( https://gerrit.osmocom.org/c/pysim/+/39742?usp=email )
Change subject: personalization: refactor ConfigurableParameter, Iccid, Imsi ...................................................................... Patch Set 14: -Code-Review (1 comment) File pySim/esim/saip/personalization.py: https://gerrit.osmocom.org/c/pysim/+/39742/comment/b7cf3efb_5b554be9?usp=email : PS13, Line 50: r"""Base class representing a part of the eSIM profile that is configurable during the > abc has no purpose and it doesn't work. My gist was that it doesn't solve exactly the problem you are trying to solve, but that doesn't mean it has no porpose and doesn't work. > The first time this comment came up, I tried to use abc to determine which > ConfigurableParameter classes are abstract. This did not work at all. Sadly code review (particularly dragging on over the better part of a year so everyone forgets about what exactly was discussed before) is not a method of how you could demonstrate what exactly was not working in which way exactly. In such instances I would appreciate a "this is the branch containing what I tried, and it does not do XYZ while I'm trying to achieve ABC". > Adding empty cruft to code is not what I do. You sound like adding type annotations is also empty cruft? If a class is not supposed to be used directly, but only inherited by other classes (one of which finally being none-abstract), it's an abstract base class. Adding the annotation by inheriting from abc.ABC shows that at the very least to whoever is reading the code, and ideally also allows the python runtime to raise meaningful exceptions if someone ever should try to instantiate the ABC directly. If you don't do that, people could just instantiate your class. > the logical reason to change the patch is simply not present. I would love to > accept your point, but explain to me why exactly you want to see abc in there. The logical point is simply: there is a python standard library method of declaring "this class is abstract and shall not be instantiated directly". If your class falls into that category, it should be declared that way. Furthermore, the code contains abc.abstractmethod decorator on a class that is not an ABC. According to the documentation this violates the abc module requirements: ``` A decorator indicating abstract methods. Using this decorator requires that the class’s metaclass is ABCMeta or is derived from it. See https://docs.python.org/3/library/abc.html#abc.abstractmethod ``` > If the reason is cosmetic, then let me know. > I will disagree and i will still have to use a simple boolean flag to make it > work as it should, You may need to do that, to solve your specific problem (different from what abc may solve). But to this point, after lots of code review I still don't fully understand the full picture, especially as I have no example/branch of "what doesn't work". I'm not trying to undestand everything in the review of this specific patch, but I'm merely saying * if the class is abstract it should be labelled as such * if you use abc.abstractmethod, the python standard library documentation says you must also mark the class as ABC I'm not saying the above is solving all of your problems in the way you are trying to solve them. -- To view, visit https://gerrit.osmocom.org/c/pysim/+/39742?usp=email To unsubscribe, or for help writing mail filters, visit https://gerrit.osmocom.org/settings?usp=email Gerrit-MessageType: comment Gerrit-Project: pysim Gerrit-Branch: master Gerrit-Change-Id: I6522be4c463e34897ca9bff2309b3706a88b3ce8 Gerrit-Change-Number: 39742 Gerrit-PatchSet: 14 Gerrit-Owner: neels <[email protected]> Gerrit-Reviewer: Jenkins Builder Gerrit-Reviewer: dexter <[email protected]> Gerrit-Reviewer: laforge <[email protected]> Gerrit-Reviewer: neels <[email protected]> Gerrit-CC: fixeria <[email protected]> Gerrit-Attention: neels <[email protected]> Gerrit-Attention: fixeria <[email protected]> Gerrit-Attention: dexter <[email protected]> Gerrit-Comment-Date: Thu, 08 Jan 2026 14:54:29 +0000 Gerrit-HasComments: Yes Gerrit-Has-Labels: Yes Comment-In-Reply-To: neels <[email protected]> Comment-In-Reply-To: laforge <[email protected]>
