Attention is currently required from: laforge, pespin.

1 comment:

File pySim/esim/saip/personalization.py:
- Patch Set #13, Line 50: r"""Base class representing a part of the eSIM profile that is configurable during the
  > re the build failure, dear Vadim, on the contrary. […]
  about the stub idea:
  - if I have to add a fake non-abstract yet abstract stub to prevent ABC from doing what it was designed to do, it defies the point of ABC, right? =) Instead I can just remove the @abstractmethod decorator to achieve the same goal.
  - I can adjust these classes here, but i want to keep other peoples' subclasses that may be out there intact, too. I would like to add the new classmethod in an *optional* way, leaving the transition to the new features up to the implementing classes -- transitions are
  - shown in the subsequent commits.
  As part of this discussion, I'd also like to mention from the future:
```
In a later patch, we generate SdKey classes by using
  `type('Xxx',...)`
instead of
  `class Xxx:`
According to python docs, they are identical:
https://docs.python.org/3/library/functions.html#type
"The following two...create identical..."
```
  However, it turns out that, as soon as ConfigurableParameter inherits from ABC, the newly created `SdKeyXxx.__module__` member suddenly points to module `abc`, not to `pySim.esim.saip.personalization` where it was actually created, and I have to set the `__module__` member explicitly to make things work again.
  (I don't really like generating classes very much, we should be generating class *instances* instead, but the choice is again to stay backwards compatible with the existing API)
  So, in all honesty, my opinion is still that ... well ... that abc serves no purpose and doesn't work, as harsh as it may sound.

To view, visit change 39742. To unsubscribe, or for help writing mail filters, visit settings.