On Tue, Jun 7, 2011 at 6:22 PM, Antoine Pitrou <solip...@pitrou.net> wrote: > On Tue, 7 Jun 2011 12:47:37 +1000 > Nick Coghlan <ncogh...@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 | 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
