
On Sun, Oct 24, 2021 at 9:34 PM Paul Moore <p.f.moore@gmail.com> wrote:
This should probably reference PEP 661 (Sentinel Values) which is being discussed on Discourse: https://discuss.python.org/t/pep-661-sentinel-values/9126
It's a different proposal, but one of the major motivating use cases (if not the only one) for sentinels is handling function default values that can't be expressed at definition times. So how the two proposals interact should be discussed *somewhere*, IMO.
Personally I'd choose to support this proposal, and take the view that it weakens the need for PEP 661 to the point where I'd prefer not to bother with that proposal.
Good point; I'll add a reference. When I was searching the stdlib for examples of different arg-passing idioms, I came across quite a number of uses of object() which weren't used for argument defaults, so while it's true that PEP 661 would lose one use-case if 671 is accepted, I still think that 661 would have plenty of value. The specific example that PEP 661 cites - traceback.print_exception() - wouldn't be able to be transformed using PEP 671 alternate defaults, unless the API were to be changed somewhat. You can't specify the traceback while leaving the value at its default, and PEP 671 is stateless with regard to multiple parameters. (That said, though: traceback.format_exception_only() could benefit from PEP 671.) ChrisA