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()" 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?
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?).
Le 24/05/2021 à 16:28, Tal Einat a écrit :
On Mon, May 24, 2021 at 3:30 AM Luciano Ramalho email@example.com wrote:
On Sun, May 23, 2021 at 3:37 AM Tal Einat firstname.lastname@example.org wrote:
I put up an early draft of a PEP on a branch in the PEPs repo: https://github.com/python/peps/blob/sentinels/pep-9999.rst
Thanks for that PEP, Tal. Good ideas and recap there.
I think repr= should have a default: the name of the class within <>: <NotGiven>.
Sentinels don't have state or any other data besides a name, so I would prefer not to force users to create a class just so they can instantiate it.
Why not just this?
NotGiven = sentinel('<NotGiven>')
I'm seriously considering that now. The issues I ran into with this approach are perhaps not actually problematic.
On the other hand, if the user must create a class, the class itself should be the sentinel. Class objects are already singletons, so that makes sense.
Here is a possible class-based API:
class NotGiven(Sentinel): pass
That's it. Now I can use NotGiven as the sentinel, and its default repr is <NotGiven>.
Behind the scenes we can have a SentinelMeta metaclass with all the magic that could be required--including the default __repr__ method.
What do you think?
One issue with that is that such sentinels don't have their own class, so you can't write a strict type signature, such as `Union[str, NotGivenType]`.
Another issue is that having these objects be classes, rather than normal instances of classes, could be surprising and confusing.
For those two reasons, for now, I think generating a unique object with its own unique class is preferable.
Sorry about my detour into the rejected idea of a factory function.
Please don't apologize! I put those ideas in the "Rejected Ideas" section mostly to have them written down with a summary of the considerations related to them. They shouldn't be considered finally rejected unless and until the PEP is finished and accepted.
Python-Dev mailing list -- email@example.com To unsubscribe send an email to firstname.lastname@example.org https://mail.python.org/mailman3/lists/python-dev.python.org/ Message archived at https://email@example.com/message/HL74JC3O... Code of Conduct: http://python.org/psf/codeofconduct/ .