[Python-Dev] [Python-checkins] cpython: Issue #12040: Expose a new attribute `sentinel` on instances of

[Nick Coghlan]

On Tue, Jun 7, 2011 at 6:22 PM, Antoine Pitrou <solipsis at pitrou.net> wrote:
> On Tue, 7 Jun 2011 12:47:37 +1000
> Nick Coghlan <ncoghlan at gmail.com> wrote:
>>
>> We should probably follow this model for threading.Thread.ident as
>> well (i.e. throwing an exception rather than returning None if the
>> thread hasn't been started yet).
>
> Well, Process.ident returns None as well ;)

Hmm, I guess in that case my preference for keeping the Thread and
Process APIs reasonably consistent just edges out my dislike of
returning None when a "you shouldn't do that" exception would be more
appropriate.

>> Also, for runtime state errors, we tend to use RuntimeError rather
>> than ValueError (e.g. see the errors thrown by
>> contextlib._GeneratorContextManager)
>
> Well, it depends. For example, closed files raise a ValueError when you
> try to do operations on them. I tend to think of RuntimeError as
> something that happens without any clear responsibility from the user,
> although that's debatable (recursion errors can occur because of a
> programming bug, but also simply because a structure is nested much too
> deeply).

Yeah, I only thought of the closed file counterexample after I had
already posted. I guess I just have a slight personal preference for
RuntimeError to flag state problems as they're less likely to be
caught up in an overly broad try statement in user code (as catching
RuntimeError seems to be less common than catching ValueError).

> Of course, current coding practice in other multiprocessing.Process
> methods and properties doesn't help, since it uses asserts to guard
> against misuse!

I have a vague recollection of an existing tracker issue complaining
about that... or am I just remembering the one that addressed similar
problems in threading?

Cheers,
Nick.

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