Eric V. Smith <e...@trueblade.com> added the comment:
I don't see any problems that need solving. My only interest in this is that I tend to think sentinels that are used for missing parameters should be exposed, and this isn't always an obvious consideration when designing an API. For example, say there's a library that has a function: open(name, type, [mode]) That is, mode is optional. I realize that in pure Python, I could find out what sentinel value they're using, unless they're playing tricks with args and kwargs. But maybe this is written in C. Now, say I want to write a wrapper around this, called myopen, and always pass in "foo" for type. I'd need to use my own sentinel: _MISSING= object() def myopen(name, mode=_MISSING) But, how do I call open? In the past, I've done things like: if mode is _MISSING: return open(name, "foo") else: return open(name, "foo", mode) That doesn't scale well if there are multiple optional parameters. In any event, this just seems like a guideline we should be aware of when adding APIs. Absent any concrete proposals for a "sentinel style guide", I don't think there's anything actionable here. I agree with Steven that it's a case-by-case thing. One size need not fit all. As to the issue referenced by Victor: I'm not sure what a style guide would bring to the table. I think the issue of whether to use a second sentinel or not could be decided in this file alone, without needed a global decision. ---------- _______________________________________ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue35123> _______________________________________ _______________________________________________ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
