From Newsgroup: comp.lang.python

A new feature coming in Python 3.15 is the “sentinel” class, useful
for creating custom values to mark the end of sequences of items, that
kind of thing
<https://docs.python.org/3.15/library/functions.html#sentinel>, <https://peps.python.org/pep-0661/>.

For those times when a simple “None” marker element is not sufficient,
this will be very convenient.

However, one limitation is that you cannot subclass the “sentinel”
class. I wonder why not? Consider this behaviour, from the PEP:

Sentinel objects are “truthy”, i.e. boolean evaluation will result
in True. This parallels the default for arbitrary classes, as well
as the boolean value of Ellipsis. This is unlike None, which is
“falsy”.

Suppose you want a sentinel to be “falsy”? The obvious way would be to subclass it and override the __bool__ method accordingly. But this is
not allowed. The PEP goes into a lot of detail about the design
rationale in other areas, but not this one.
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.lang.python

Lawrence D’Oliveiro <ldo@nz.invalid> writes:

For those times when a simple “None” marker element is not sufficient, this will be very convenient.

object() has always worked for me.
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.lang.python

On Sun, 10 May 2026 21:01:00 -0700, Paul Rubin wrote:

Lawrence D’Oliveiro <ldo@nz.invalid> writes:

For those times when a simple “None” marker element is not
sufficient, this will be very convenient.

object() has always worked for me.

I have done the same, on a few occasions. That’s been a common idiom
among Python programmers since practically forever. The PEP discusses
why this is less than an optimal solution: less-than-explanatory
diagnostics, and difficulty with type signatures for static typing.
Also, an “is” comparison fails if you should (inadvertently or
otherwise) make a copy of your sentinel object.
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.lang.python

On 2026-05-11, Lawrence D’Oliveiro <ldo@nz.invalid> wrote:

On Sun, 10 May 2026 21:01:00 -0700, Paul Rubin wrote:

Lawrence D’Oliveiro <ldo@nz.invalid> writes:

For those times when a simple “None” marker element is not
sufficient, this will be very convenient.

object() has always worked for me.

I have done the same, on a few occasions. That’s been a common idiom
among Python programmers since practically forever. The PEP discusses
why this is less than an optimal solution: less-than-explanatory
diagnostics, and difficulty with type signatures for static typing.

I've always used (and seen) "SENTINEL = []"...

Also, an “is” comparison fails if you should (inadvertently or
otherwise) make a copy of your sentinel object.

That doesn't seem terribly likely to happen by accident though.
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.lang.python

On 5/10/26 19:17, Lawrence D’Oliveiro wrote:

A new feature coming in Python 3.15 is the “sentinel” class, useful
for creating custom values to mark the end of sequences of items, that
kind of thing
<https://docs.python.org/3.15/library/functions.html#sentinel>, <https://peps.python.org/pep-0661/>.

For those times when a simple “None” marker element is not sufficient, this will be very convenient. <SNIP>

Forgive me, but this smells of Feeping Creaturism to solve a not very important question
at the expense crufting up the language and decreasing clarity.

I have seen this happen with every single language I ever used except perhaps, assembler, C, and Forth.

Oh well, there's an opportunity here for someone to excise the noisy PEPs and create Python Lite.


--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.lang.python

On Mon, 11 May 2026 19:51:21 -0500, Tim Daneliuk wrote:

On 5/10/26 19:17, Lawrence D’Oliveiro wrote:

A new feature coming in Python 3.15 is the “sentinel” class, useful
for creating custom values to mark the end of sequences of items, that
kind of thing
<https://docs.python.org/3.15/library/functions.html#sentinel>,
<https://peps.python.org/pep-0661/>.

For those times when a simple “None” marker element is not
sufficient, this will be very convenient.

Forgive me, but this smells of Feeping Creaturism to solve a not
very important question at the expense crufting up the language and decreasing clarity.

In order to be forgiven, you will have to explain why you think so.
Some of us have done enough Python programming that we can see the
utility of such a feature, minor as it is.
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.lang.python

Tim Daneliuk <info@tundraware.com> writes:

Oh well, there's an opportunity here for someone to excise the noisy
PEPs and create Python Lite.

https://micropython.org
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.lang.python

On 5/11/26 21:42, Lawrence D’Oliveiro wrote:

On Mon, 11 May 2026 19:51:21 -0500, Tim Daneliuk wrote:

On 5/10/26 19:17, Lawrence D’Oliveiro wrote:

A new feature coming in Python 3.15 is the “sentinel” class, useful
for creating custom values to mark the end of sequences of items, that
kind of thing
<https://docs.python.org/3.15/library/functions.html#sentinel>,
<https://peps.python.org/pep-0661/>.

For those times when a simple “None” marker element is not
sufficient, this will be very convenient.

Forgive me, but this smells of Feeping Creaturism to solve a not
very important question at the expense crufting up the language and
decreasing clarity.

In order to be forgiven, you will have to explain why you think so.
Some of us have done enough Python programming that we can see the
utility of such a feature, minor as it is.

I have also done plenty of Python programming (and C, and Fortran, and BASIC, and
many assemblers, and ...).

I stipulate that there is some utility to a sentinel feature. But it does so at a
cost. That cost is bloating the language definition with yet another feature that
has fairly limited application beyond what is already possible.

I've seen this happen over and over again in a variety of languages. "Elegant" solutions are proposed to legitimate problems but these solutions make the language bigger, harder to master, and harder to maintain.

True elegance comes from a reduction of complexity and improving regularity while
expanding utility. It does not come from just gluing on more and more new features.

I don't maintain Python, and the people who do are certainly welcome to add anything they want. I simply wanted to observe that - based on past history - this will eventually lead to a bloated and less usable language.

It's an opinion, not a law of nature ...
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.lang.python

On 5/12/26 03:03, Paul Rubin wrote:

Tim Daneliuk <info@tundraware.com> writes:

Oh well, there's an opportunity here for someone to excise the noisy
PEPs and create Python Lite.

https://micropython.org

Thanks Paul, that's very cool. Added to my quiver of arrows ;)
--- Synchronet 3.22a-Linux NewsLink 1.2