Re: Feedback before submission of PEP 661: Sentinel Values

Hello, Thanks for this nice PEP, I have just read it. I think it is a good thing to add to Python and will enable cleaner code. I support the idea to have common sentinels suggested by Christopher Barker. For example, a common confusion is to identify None with NULL in DB, but then when you are filtering rows in a SQL query generated by a framework function, you have to do convoluted things because most frameworks do not distinguish "Do not filter" and "Keep only rows where value is NULL", because the vocabulary of sentinels is too limited. Some sentinels could be created also for some constants of R language for example. Anyway, extending the language with common sentinels can be done later. But it would be nice to really think about it. Regarding the type of Sentinels, the proposition in the PEP is not perfect. Recently, I used MY_SENTINEL = object() TypeMySentinel = Literal(MY_SENTINEL) in my code. But what I would have like to be able to do is just : TypeMySentinel = MY_SENTINEL exactly like None "is" its own type. However, it was rejected on import of the corresponding file, when using it in function signature. It would be really nice if all sentinel values could have this feature to be their own type. Last, I spotted a typo in the PEP : "Most common exiting idioms" -> "existing' Thanks, best regards, Laurent Lyaudet, PhD

Good example— wouldn’t it be nice if all the database interaction packages used the same Sentinel for this? In that case it would go in the DB api, but the idea holds. -CHB -- Christopher Barker, PhD (Chris) Python Language Consulting - Teaching - Scientific Software Development - Desktop GUI and Web Development - wxPython, numpy, scipy, Cython

Christopher Barker writes:
The question is whether it's an *example* of a common need, or a *nearly unique use case* of a generally useful distinction that justifies a new (semi-)singleton. Tal says that at least in the stdlib and the other cases he's seen it's almost always an application-specific need. We need to see a *list* of generally useful sentinel classes that aren't served by Tal's "_local_sentinel = Sentinel()" idiom. Otherwise such sentinels can be added ad hoc to specific (though widely used) modules as module-specific APIs. Steve

Btw, just to give some context: The reason we need sentinels at all is because our APIs don't like to wrap the happy case. As an example: So in Python, when you do {'a': 'foo'}.get('a') you get 'foo' directly. That's convenient. In eg Haskell the equivalent operation gives you a wrapped 'foo'. ghci> :m + Data.Map ghci> Data.Map.lookup "a" (Data.Map.fromList [("a", "foo")]) Just "foo" The benefit is that you can tell these two cases apart: ghci> Data.Map.lookup "b" (Data.Map.fromList [("c", Nothing)]) Nothing ghci> Data.Map.lookup "c" (Data.Map.fromList [("c", Nothing)]) Just Nothing The drawback is that you have to unwrap your happy case (you have to remove the `Just`.) Many Python functions side-step the need for a sentinel by using exceptions: the result of {'some-key': None}['some-key'] is unambigous, but needs exception handling. Using common sentinels would be totally besides the point: what if you want to stick these common sentinels in eg a dict (or any other structure whose operations sometimes use sentinels)?

Good example— wouldn’t it be nice if all the database interaction packages used the same Sentinel for this? In that case it would go in the DB api, but the idea holds. -CHB -- Christopher Barker, PhD (Chris) Python Language Consulting - Teaching - Scientific Software Development - Desktop GUI and Web Development - wxPython, numpy, scipy, Cython

Christopher Barker writes:
The question is whether it's an *example* of a common need, or a *nearly unique use case* of a generally useful distinction that justifies a new (semi-)singleton. Tal says that at least in the stdlib and the other cases he's seen it's almost always an application-specific need. We need to see a *list* of generally useful sentinel classes that aren't served by Tal's "_local_sentinel = Sentinel()" idiom. Otherwise such sentinels can be added ad hoc to specific (though widely used) modules as module-specific APIs. Steve

Btw, just to give some context: The reason we need sentinels at all is because our APIs don't like to wrap the happy case. As an example: So in Python, when you do {'a': 'foo'}.get('a') you get 'foo' directly. That's convenient. In eg Haskell the equivalent operation gives you a wrapped 'foo'. ghci> :m + Data.Map ghci> Data.Map.lookup "a" (Data.Map.fromList [("a", "foo")]) Just "foo" The benefit is that you can tell these two cases apart: ghci> Data.Map.lookup "b" (Data.Map.fromList [("c", Nothing)]) Nothing ghci> Data.Map.lookup "c" (Data.Map.fromList [("c", Nothing)]) Just Nothing The drawback is that you have to unwrap your happy case (you have to remove the `Just`.) Many Python functions side-step the need for a sentinel by using exceptions: the result of {'some-key': None}['some-key'] is unambigous, but needs exception handling. Using common sentinels would be totally besides the point: what if you want to stick these common sentinels in eg a dict (or any other structure whose operations sometimes use sentinels)?
participants (4)
-
Christopher Barker
-
Laurent Lyaudet
-
Matthias Görgens
-
Stephen J. Turnbull