python module organisation

Question

I am writing a python library that backs up and organises scientific data. lets call it dataapp

I would like to lay out my directory as follows:

core/
operations/
cli_interface.py

core contains all the data classes and the class for a data repository, and all the code is standalone, with no dependancies. operations contains all of the actions, like saving, updating, backing up data, operations does however depend on core. core is not a child of operations and should have the ability to be used on its own.

However importing code from core into operations seems like an ugly thing because I would have to import from relative paths and from the parents.

Another option for importing is for install dataapp on the machine globally, in that case operations can import from core easily.

My question is: is the above recommended, or is there a better way to lay out my code?

Answer 1

Try this layout:

core/
 __init__.py
 functions.py
operations/
 __init__.py
 actions.py
test.py

Note: __init__.py files, they are just empty files to define package with a name coincided with the directory name.

Where functions.py with core functions defintions:

def core_function():
 print "core function"

Module actions.py will have such connection with core:

from core import functions
def simple_action():
 functions.core_function()

In your applicationtest.py you could use it as follows:

from core import functions
from operations import actions
functions.core_function()
actions.simple_action()

Note also: that core and operations packages are referenced by whole path - not relative, i.e. if you had lab.sci.core structure you'd use from lab.sci.core and from lab.sci.operations import commands in your test.py application and actions.py module.

• Eoin Murray: this solves my issure....I am now using from lab.core import functions in the operations module. My mistake was trying to use from core import functions. But you have now cleared that up for me.

Answer 2

The setup you sketch is perfectly fine. If every module were only allowed to import from its own submodules (a strict tree structure), you could never share code between modules. Tidy module structures are directed acyclic graphs (no mutual imports), not necessarily trees.

• Eoin Murray: how would you recommend I do it, by installing the app globally and importing, or using relative paths?
• Fred Foo: @EoinMurray what do you mean by relative paths?
• Eoin Murray: Ill need to put sys.path.append( <path to core> ) in operations. I dont see how I can import naturally.
• Fred Foo: @EoinMurray The Python tutorial explains how to set up packages. Changing sys.path in module code is a code smell.

Answer 3

How about it:

cli_interface.py
operations/
core

so core be a child of operation, because core is a data to be used by operations module only.

• Eoin Murray: no, perhaps I was not clear...core is not a child of operations only. It should be allowed to be used on its own. I will update the question to reflect this.
• Tok Soegiharto: @EoinMurray, if so, a plain structure will be a better solution.

Answer 4

There is nothing wrong with your structure. But if you want to be more verbose in imports, this works too:

cli_interface.py
dataapp/
 core/
 operations/

Then you'd do

from dataapp import core