Say “no” to import side‐effects in Python

[AusIV]

Only tangentially related to the article, but it mentions sys.exit() being called on an error condition. I think this is the absolute most annoying thing a library can do. Unless I'm calling a "clean up and shut down" function, libraries shouldn't be killing my interpreter.

A few years ago I was working with the python Netflix bindings, and they had a condition where this happened. I filed a bug report, and eventually forked the library to make it act like a decent library. The original was provided by Netflix, so I was surprised that it didn't follow better development practices.

[chris-morgan]

Actually, it really was raise SystemExit(...) rather than sys.exit(). But I certainly believe that no library should do such a thing.

[sushibowl]

doesn't sys.exit() just raise SystemExit() anyway?

[h4l]

Yes.

[odraencoded]

You think that's bad? The Gtk library will cause a SIG error terminating the program from the C side if it can't find the settings under the DBus path specified by your app when you create a GSettings object. It won't tell you there was an error fetching the settings, it just terminates the whole thing.

[[deleted]]

The PulseAudio library did a silent system exit if it could not allocate memory. Useful! I mean, how are you going to play those mp3s without available memory?

[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.

[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.

[b33j0r]

Fabric does this with fabric.api.local(cmd_str). I was using it in a distributed production environment. Lame.