On Thu, Feb 2, 2012 at 11:01 AM, Eric V. Smith <e...@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.dela...@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 | ncogh...@gmail.com | Brisbane, Australia _______________________________________________ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
