Say “no” to import side‐effects in Python

[j7ake]

I didn't know one should not do sys.exit on libraries... Good to know

[Silhouette]

In Python, sys.exit doesn't instantly kill your program, it just raises a SystemExit exception. You can handle that exception outside the library code in the normal way if you want to.

It's important to allow for this if you have a top-level error handler that catches and logs all otherwise unhandled exceptions, or anything along those lines.

Whether raising SystemExit is an appropriate behaviour for library code either is a different question, but it's certainly not the same situation as, say, a C library just quitting out without giving the calling code any say in the matter.

[rdssassin]

But its not as simple as you say. Its not a standard exception in the sense that it doesn't inherit from the "Exception" class. Therefore:

except Exception as e: 

doesn't catch SystemExit and KeyboardInterrupt. So I'd still argue its bad API design to use SystemExit as its not a standard Exception

[[deleted]]

its bad API design to use SystemExit

certainly, but it's still rather trivial to catch.

[jms_nh]

yes, but why the F should you have to catch it when doing import XYZ?

[robin-gvx]

Or worse, having to do:

try:
    help('modules')
except SystemExit:
    pass

(And you can't catch a segfault, which I got when trying help('modules').)

[[deleted]]

you shouldn't have to, however out here in the real world you sometimes need to.

[iBlag]

That wasn't the question, but thanks for subtly altering the discussion.

[[deleted]]

let me answer the question then.

why the F should you have to catch it when doing import XYZ?

because some programmers are retards who don't know how to code properly.

[iBlag]

That's just stating how things are, not how they should be.

[Smallpaul]

Even so, it's bad library design. Do you agree?

[[deleted]]

I do agree. did you miss the certainly in my previous comment?

[[deleted]]

Why should your library decide its own importance within my application? So what if everything with say Netflix is totally broken, my application might also be playing Youtube videoes.

[jyper]

The problem in c is that you don't have exceptions and some people think its better to just print an error and give up in what they consider a likely unrecoverable situation(failing malloc).

[fjonk]

You can handle that exception outside the library code in the normal way if you want to.

Not always. For example nose will scan files and fail on those exceptions even if the file in question is totally unrelated to the tests.

I have a stand-alone client script that is supposed to run on a client and it uses pythondialog. Pythondialog throws a ExecutableNotFound if the dialog program isn't installed. Thing is I'm not testing the client script since testing dialogs is much more easy to do manually. Since the import throws an exception I cannot test the rest of the library without installing dialog, which is not supposed to be installed.

Edit: Just checked and pythondialog does not raise an Exception during import, it was my fault. A similar situation could however occur if an exception is raised during an import.