[Python-Dev] PEP 409 - final?

Nick Coghlan ncoghlan at gmail.com
Thu Feb 2 02:43:01 CET 2012


On Thu, Feb 2, 2012 at 11:01 AM, Eric V. Smith <eric at trueblade.com> wrote:
> On 2/1/2012 7:49 PM, Nick Coghlan wrote:
>> On Thu, Feb 2, 2012 at 10:44 AM, Tim Delaney
>> <timothy.c.delaney at gmail.com> wrote:
>>>> 3) Should it be an exception, or just inherit from object?
>>>>   Is it worth worrying about somebody trying to raise it, or
>>>>   raise from it?
>>>
>>> If it's not actually an exception, we get prevention of instantiation for
>>> free. My feeling is just make it a singleton object.
>>
>> Yeah, a new Ellipsis/None style singleton probably makes more sense
>> than an exception instance.
>
> But now we're adding a new singleton, unrelated to exceptions (other
> than its name) because we don't want to use an existing singleton (False).
>
> Maybe the name difference is good enough justification.

That's exactly the thought process that led me to endorse the idea of
using False as the "not set" marker in the first place.

With None being stolen to mean "No cause and don't print the context
either", the choices become:

- set some *other* exception attribute to indicate whether or not to
print the context
- use an existing singleton like False to mean "not set, use the context"
- add a new singleton specifically to mean "not set, use the context"
- use a new exception type to mean "not set, use the context"

Hmm, after writing up that list, the idea of using "__cause__ is
Ellipsis" (or even "__cause__ is ...")to mean "use __context__
instead" occurs to me. After all, "..." has the right connotations of
"fill this in from somewhere else", and since we really just want a
known sentinel object that isn't None and isn't a meaningful type like
the boolean singletons...

Regards,
Nick.

-- 
Nick Coghlan   |   ncoghlan at gmail.com   |   Brisbane, Australia


More information about the Python-Dev mailing list