
On Tue, May 25, 2021 at 11:25 AM Pascal Chambon <pythoniks@gmail.com> wrote:
Hello, and thanks for the PEP,
I feel like the 3-lines declaration of a new sentinel would discourage a bit its adoption compared to just "sentinel = object()"
I now tend to agree. The new version of the draft PEP proposes a simpler interface: NotGiven = sentinel('NotGiven')
From what I understand from the PEP, if new classes are defined inside the closure of a factory function, some Python implementations would have trouble copying/pickling them?
The reference implementations I propose take care of this. I'll make sure that everything works in popular alternate implementations such as PyPy.
Would it be doable to have a single Sentinel class, whose instances store their representation and some autogenerated UUID, and which automatically return internally stored singletons (depending on this UUID) when called multiple times or unpickled ? This would require some __new__() and unpickling magic, but nothing too CPython-specific (or am I missing something?).
That's certainly doable, and I believe that there are existing implementations of sentinels that use this method. But since classes are singletons, and it's simple to make a class that always returns the same object, there's no need for setting a UUID and implementing custom pickling logic as you suggest. Another drawback of this approach is that each sentinel value wouldn't have its own dedicated type. - Tal