Python – Defining Exit Method Before Importing

importpython

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)

Best Answer

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.

Related Solutions

Python Documentation – Defining Data Structures

If you are writing code that may be used by other programmers in isolation to you, and you are using data structures that are beyond simple built-ins, consider whether or not you can encapsulate them as classes.

Lets look at some example methods and what they return.

def getMatrix(**args):

Calling this I can presume that the output will be an list of lists wth some simple value inside. Not much help needed.

def getCharacterCounts(**args):

In this, I could presume that based on the arguements I'll get a dictionary where each key is a character and then the value will be a count based on the occurances in some string.

def getPerson(**args):

Ah, now we are getting into trouble. A person is a complex thing, and I could store it as a dictionary, like so:

person = {  name:"Bob",
            age: 37,
            date_of_birth: "1932-01-15",
            hobbies:['programming','arguing on the internet', 'cross stitch'],
         }

But, as this data structure gets larger, more fields occur, the example gets bigger and then the documentation needs to start including how to resolve issues when values conflict - for example, unless we are transported back to the year 1969, the date-of-birth and age are inconsistent.

In summation, if you are using a data structre that is varied in structure and includes some "algorithmic workings" then perhaps its time to call upon the power of Object-Oriented Programming^TM.

Python – Setting up folders and importing modules in Python

I cannot comment so instead I'll answer or lead you there with rhetorical questions:

First, how are you intending on launching as well as using this program? You are building a python package by using __init__.py's but you are executing a module (bin/app.py) within the package as __main__. This is not a typical setup.

Do you plan on importing this package of yours into some other python script? Maybe you don't need a package at all and can use a few scripts. Generally all python files related to some function would be in one cohesive package (perhaps you don't need that top-level __init__.py).

Did you mean for bin/app.py to be executable since it appears that's your only use of it? Add a #!/usr/bin/env python run command to the top of the file, and IMO make the file called app and executable $ chmod +x bin/app.

It would be good to google how python finds modules, how to construct a package, and how env's PYTHONPATH and sys.path work. If your module name doesn't make it to sys.path or is relative to your current directory python won't find it. I added some links below.

If you don't intend on using a python package mechanics you could simply (answer) perform a sys.path.append(os.path.join(os.getcwd(), 'Fragment_Maker')) or sys.path.append(os.path.join(os.dirname(__file__), '..', 'Fragment_Maker')) before your import maker, depending on how you intend on launching your application. Otherwise your question cannot be answered without assumptions from above (e.g. maybe you'll want to put your python script app at top level, keep Fragment_Maker a package, perform a from Fragment_Maker import maker), but assuredly you can now figure it out with these resources: