Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add to builtins #5

Closed
bharel opened this issue Aug 15, 2021 · 3 comments
Closed

Add to builtins #5

bharel opened this issue Aug 15, 2021 · 3 comments

Comments

@bharel
Copy link

bharel commented Aug 15, 2021

Hey Tal,

Instead of creating a module with a single function, and since sentinel is used 468 times in 58 different python files just in the standard library, I believe it justifies adding it to the builtins.
image

The usage of sentinel values is vast, and almost every Python module I write or contribute to has created at least one sentinel value.

Importing the module just about everywhere sounds a bit counter-productive, as creating sentinel objects should be as simple as creating a string, a "None" object, or an integer. Plus, I do not see how the "sentinels" module grows to have more than the single "sentinel" class. No matter how it grows, it'll break the uniqueness and thus one of the requirements of a sentinel value.

Lots of love ❤️
Bar Harel.

@tusharsadhwani
Copy link

Hey @bharel

This is a reference implementation. The goal has always been to get this into stdlib. See: https://peps.python.org/pep-0661/

@bharel
Copy link
Author

bharel commented Mar 11, 2022

Not stdlib, built-ins. It is common enough to justify it :-)
The proposal constantly talks about stdlib and I believe it should take a slightly different approach.

@taleinat
Copy link
Owner

taleinat commented Sep 6, 2022

Thanks for the suggestion @bharel!

I disagree that this should be added to the built-ins, though. And even if I agreed, I very much doubt that that would be accepted; there would need to be a very strong argument in favor of adding something to Python's built-ins; much stronger than the one brought forth here.

The reason that such a strong argument would be needed is that adding a built-in inherently breaks backwards-compatibility: Every built-in is a name that everyone must be careful not to override with names of variables, classes, modules etc.

@taleinat taleinat closed this as completed Sep 6, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants