How to organize the source code of an application created using SQLAlchemy and GUI?

I am developing an application using SQLAlchemy and wxPython, which I am trying to save in separate modules consisting of business logic, ORM and a graphical interface.

I'm not quite sure how to do this in a pythonic way.

Given that mapping() should be called in orther for the objects to be used, I thought about putting it in the __init__.py logic of the business process, but keeping all the table definitions in a separate orm.py module.

Should I store something like:

 /Business /__init__.py | mapping (module1.Class1, orm.table1) | /module1.py Class1 /orm.py import table1 = Table() /GUI /main.py | import business /crud.py 

or something like

 /Business /__init__.py | import | /module1.py Class1 table1 = Table() mapping (module1.Class1, orm.table1) /GUI /main.py | import business /crud.py 

Is the first approach recommended? Is there any other option? I saw the second way, but I don’t like to enter the database processing code and the business class logic code in one module. Am I overdoing it? Is this really not a problem?

+6
python version-control sqlalchemy directory-structure
source share
1 answer

I find this document from Jp Calderone to be great advice on how to (not) structure a python project. After that you will have no problems. I will reproduce all the text here:

Python project file system structure

Do

  • The name of the directory is something related to your project. For example, if your project is called β€œTwisted,” name the top-level directory for your Twisted source files. When you do this, you must include the number Suffix version: Twisted-2.5 .
  • create a Twisted/bin and put your executables there if you have any. Do not give them the .py extension, even if they are Python source files. Do not enter code in them, except for import and calling the main function is defined somewhere else in your projects.
  • If your project is expressed as a single Python source file, then enter it in a directory and name it something related to your project. For example, Twisted/twisted.py . If you need several source files, create a package instead of ( Twisted/twisted/ , with an empty Twisted/twisted/__init__.py ) and put the source files in it. For example, Twisted/twisted/internet.py .
  • putting your unit tests in a sub-package is your package (note - this means that the only Python source file above was a trick - you always need less than one other file for your device tests). For example, Twisted/twisted/test/ . Of course, make it a package with Twisted/twisted/test/__init__.py . Put the tests in files like Twisted/twisted/test/test_internet.py .
  • add Twisted/README and T wisted/setup.py to explain and install the software, respectively, if you feel good.

Not

  • put your source in a directory called src or lib . This makes it difficult to work without installation.
  • put your tests outside of your python package. This makes it difficult to run tests against the installed version.
  • create a package, __init__.py , and then put all your code in __init__.py . Just make a module instead of a package, it's easier.
  • try to come up with magic hacks so that Python can import its module or package without adding a user to the directory containing its import path (either through PYTHONPATH , or some other mechanism). You will not handle all cases correctly, and users will get angry with you when your software does not work in their environment.
+5
source share

All Articles