I was looking at the example found here [1] which begins with:

[1] http://docs.python.org/py3k/library/imp.html#examples

def __import__(name, globals=None, locals=None, fromlist=None):
    # Fast path: see if the module has already been imported.
    try:
        return sys.modules[name]
    except KeyError:
        pass

I was wondering if the formulation

    if name in sys.modules:
        return sys.modules[name]

would be equivalent. IOW, is using try/except here only a matter of
style or a necessity?

I'm suspecting that maybe, in multithreaded environments, the second
option may be subject to a race condition, if another thread removes
name frome sys.modules between the if and the return, but as I'm not
very familiar (yet) with Python threads, I'm not sure it is a real
concern here.

And maybe there are other reasons I'm completely missing for prefering
EAFP over LBYL here?

Thanks in advance for your comments.

If you expect that most of the time the module will be found, the
try...except version will be faster. If you expect that most of the time
the module will not be found, the "if name in" version will be faster.

But see also:

But in principle, yes, it is a race condition and yes it is a (small)
concern. Since it is so easy to avoid even this tiny risk, why not use
the try...except version and avoid it completely?

Obviously, you can use 'try:' only, if there is the possibility to
produce an exception on failure. In the other cases you must use the
explicit test by 'if'.

Best regards,

In the particular case of __import__, I guess speed is not crucial since
I doubt import often happen within a program's inner loop. But I'll
remember that point for other cases anyway.

Thanks for your explanations.

The distinction in performance between the success and failure modes of
the try/catch isn't nearly as large as one of the other responses might
lead you to believe.  For example, a for loop generally terminates with
a raise (of StopIteration exception), and that doesn't convince us to
replace it with a while loop.  Besides, in this case, the except code
effectively includes the entire import, which would completely swamp the
overhead of the raise.

If we assume the question was more generally about EAFT vs. LBYL, and
not just about the case of accessing the system data structure
sys.modules, then the issues change somewhat.

If we do a LBYL, we have to know that we've covered all interesting
cases with our test.  Multithreading is one case where we can get a race
condition.  There are times when we might be able to know either that
there are not other threads, or that the other threads don't mess with
the stuff we're testing.  For example, there are enough problems with
import and threads that we might just have a development policy that (in
this program) we will do all our imports before starting any additional
threads, and that we will never try to unload an import, single threaded
or not.  But for other conditions, we might be affected either by the
system or by other processes within it.  Or even affected by other
asynchronous events over a network.

If we do an EAFP, then we have to figure out what exceptions are
possible.  However, adding more exceptions with different treatments is
quite easy, and they don't all have to be done at the same level.  Some
may be left for our caller to deal with.  I think the major thing that
people mind about try/catch is that it seems to break up the program
flow.  However, that paradigm grows on you as you get accustomed to it.

--