PEP 661: Sentinel Values

[encukou (Petr Viktorin)]

@taleinat

Could it be simplified? Perhaps by introducing limitations that can be lifted in the future, as we have more experience with sentinels?

I’ve tried to keep this as simple as possible. Suggestions that would simplify further would be welcome.

Sure! The question was meant as a preface to my (sometimes implied) suggestions :‍)

@taleinat

[Are] there use cases for pickling sentinels that aren’t module globals?

[…] Having objects which don’t behave as expected after pickling+unpickling or copying leads to delicate, hard-to-debug bugs.

I agree with that. I was thinking about raising an exception when someone attempts to pickle a non-global sentinel.

@taleinat

Did you think about passing the module name explicitly?

Yes, but that is unexpected, and it is unnecessary in the most common cases. It’s more generic but makes the API more complex and readers of the code need to learn more. I’d rather avoid that.

This is API intended for library maintainers, who are creating their own APIs and want those to be pretty. IMO, it’s appropriate to lean towards more explicit (but verbose) API than usual.

Also, consider that Flask, a framework that tends to avoid boilerplate code, makes you specify the module name:

from flask import Flask
app = Flask(__name__)

… and I don’t think people find it overly complex to learn.

@taleinat

The new module would break third-party modules named sentinels

I think that’s nearly unavoidable these days, except if we add this to an existing stdlib module, which seems reasonable to me.

Yup. But the PEP needs to acknowledge it, and you should probably get the maintainer of sentinels on PyPI to agree with breaking their project.