4

This breaks nothing (in my experience), but lots of things "don't break anything" and are still wrong.

#! /usr/bin/env python
"""Short description of this module."""

def preferred_exit_method(*args):
    #code for exiting as desired

try:
    import foo
    import bar
    import eggs
except ImportError as e:
    #code code code
    preferred_exit_method(e)

So, clearly defining the program's behavior on exit, then using it during the import process can't be too terrible, right? But it goes against the oft-cited PEP 8, which states that modules should be absolutely be imported before anything global.

It seems like an unrisky proposition, but then there's always something like this:

#! /usr/bin/env python
"""Description of module"""

def exit_of_choice(*args):
    #code code code
    sys.exit(0)

try:
    import sys
    import other_things
except ImportError as e:
    exit_of_choice(e)

Apart from writing code that never needs to do this because it is perfect and never fails at anything, is there a reason besides PEP 8 and "other Python people will be cross with you" not to do this? (well, I'm less concerned with the latter - even though sys wouldn't typically fail to import, I still sort of hate that on principle)

2

is there a reason besides PEP 8

Multiple module interaction

Your code becomes much more troublesome when there are multiple modules there isn't a good way to parameterize the modules with the code you have. So you're left with 2 choices:

  • Duplicated the custom import-exit in every module that needs to import modules (or at least the imports you want to customize)
  • Centralize all your imports in one module and have subsequent modules import from the central module for use in their local namespace.
  • Only use it in one place, but an import of a particular module may or may not come from your custom import-exit code. Any number of other imports may cause a different import to initialize the module in sys.modules.

It should be written as a custom importer

There is a better way. If you want to customize imports Python has facilities for this. They are called import hooks and you can write a hook that does a lookup against a white (or black) list of modules whose import you want to customize. You can then have the hook exit explicitly when the import fails.

  • So what if preferred_exit() is intended to be used as part of the program's regular use? That's part of what I'm getting at here; we have a single, beautiful 'exit strategy' for a script, and using it during the import process is as beneficial as using it at other points. – user112358 Dec 31 '13 at 20:57
  • 1
    @Stick: You can use a preferred_exit(). You just have to be aware of the complications that may occur when including things like exceptions, imports and things of that nature. – dietbuddha Jan 1 '14 at 21:20
1

It should be noted that you could defined preferred_exit_method inside the exception block:

#! /usr/bin/env python
"""Short description of this module."""


try:
    import foo
    import bar
    import eggs
except ImportError as e:
    def preferred_exit_method(*args):
        #code for exiting as desired

    #code code code
    preferred_exit_method(e)

This does the same thing without any globals being created before the import.

0

While what you are doing does go against convention, it is not wrong. If your program needs to do something special upon exit, it is worth sacrificing some of the organization in it, especially if you do not mind that much if "python programmers are cross with you". There are few performance issues when modules are imported later in the program, and properly exiting seems like something that should be of higher priority. That being said, I do have a solution that will organize things to get the best of both worlds. You could have two files. One has the preferred exit method. This will run the other file, and address all of the other file's errors. That means that that file's errors will always be addressed properly.

  • this post is rather hard to read (wall of text). Would you mind editing it into a better shape? – gnat Dec 24 '13 at 18:22
  • 2
    I could add a few enters in seemingly random places to break it up, but this is really a cohesive paragraph. While I could also include code, it really wouldn't help clarify my point. I understand it may seem like a lot to read, but this is honestly shorter than most answers. – trevorKirkby Dec 29 '13 at 2:31

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy