Python tissue engineering directory

On how to organize a good Python project directory structure, there are already some consensus has been the directory structure. In Stackoverflow of this issue on, we can see the discussion of Python directory structure.

That said, there has been very good, and I do not intend to re-create the wheel cited a variety of different ways, and there I said my understanding and experience.

Assuming your project is named foo, I recommend comparing the most convenient directory structure like this will suffice:

Foo/
|-- bin/
|   |-- foo
|
|-- foo/
|   |-- tests/
|   |   |-- __init__.py
|   |   |-- test_main.py
|   |
|   |-- __init__.py
|   |-- main.py
|
|-- docs/
|   |-- conf.py
|   |-- abc.rst
|
|-- setup.py
|-- requirements.txt
|-- README

Explain briefly:

bin/: Some items stored in the executable file, named of course, you can script/also line the like.
foo/: Store all the project's source code. (1) all the source code modules, packages should be placed in this directory. Do not put the top-level directory. (2) its sub- tests/storage unit test code; inlet (3) program is preferably named main.py.
docs/: Store some documents.
setup.py: Installation, deployment, script packaged.
requirements.txt: Python package store a list of external software dependencies.
README: Project documentation.

In addition, there are a number of programs are given more and more content. For example LICENSE.txt, ChangeLog.txtfiles, etc., I have not listed here, because these things are mainly open source project when the need to use. If you want to write an open source software, how to organize the directory, you can refer to this article .

Here, then simply talk about my understanding of these directories and personal demands it.

About README

I think this is that each project should have a file, the purpose is to be able to brief information of the project description, allowing readers to quickly understand the project.

It should be noted that the following matters:

The basic functions of the software localization, software.
The method of running code: installation environment, start commands.
A brief description of the use.
Code directory structure, a more detailed description can point the basic principles of software.
Frequently asked questions.

I think there are more than a few points is good README. In the early days of software development, because the development process is not clear or above may change, not necessarily to all the information will be complemented at the outset. But at the end of the project, is the need to write such a document.

About requirements

python project must contain a requirements.txt file, used to record all dependencies and its exact version number. In order to deploy the new environment.

The official document:

Pip’s documentation states

pip description

freeze Output installed packages in requirements format.

list List installed packages.

Use pip generation in virtual environments (otherwise it will generate a lot of local data package, after installation or upgrade package, it is best to update this document):

pip freeze> requirements.txt # output file to the local environment package

When you need to create a complete copy of the virtual environment, you can create a new virtual environment and run the following command on its:

pip install -r requirements.txt # The package installation files for

Requirements.txt demand file contents example:

alembic==0.8.6

bleach==1.4.3

click==6.6

dominate==2.2.1

About setup.py

In general, use setup.pypacking to manage code, installation and deployment issues. The industry standard is written in Python popular packaging tools setuptools to manage these things. This mode is commonly used open source projects. But here's the core idea of not using standardized tools to solve these problems, but said that a project must have a deployment tool to install, can be quickly and easily installed on a new machine on the environment, the code will be deployed and running stand up.

I stepped on this pit.

When I first came into contact with Python writing project, installation environment, deploy code, run the program the whole process is done manually, I encountered the following problems:

When the installation environment often forget to recently added a new Python package, the results of a run to the line, the program wrong.
Version of the Python package dependency problems, sometimes we used in the program is a version of the Python package, but the official has the latest package, installed by manually installing it may be wrong.
If you rely on a lot of packages, then one by one, these things depend very time-consuming installation.
New students started writing project, the program will be up and running very troublesome, because it may often forget how to install various dependencies.

setup.pyThese things can be automated together, improve efficiency and reduce the probability of error. "Complicated things automated, can automate things must be automated." Is a very good habit.

setuptools the document relatively large, new to the case, you may not find good entry point. Learning technology way is to see how others are using, you can refer to a Python Web framework, how the flask was written: setup.py

Of course, the simple point write their own installation script ( deploy.sh) alternative setup.pyis also not a bad idea.

About conf.py

Note that in the above directory structure, there is no will conf.pyon the source directory, but on the docs/directory.

Many projects use practices for the configuration file is:

Profiles written in python one or more files, such as conf.py. here
Project which module to use this configuration file directly through the import confuse of this configuration in code form.

I do not agree with this approach:

This makes it difficult to unit test (due to internal module dependencies external configuration)
On the other hand profile as the user interface to the control program, the path to the file should be specified freely by the user.
Bad reusability program components, such as through hard-coding all the code modules such that the modules are most dependent on conf.pythis file.

So, I think using the configuration and better way,

Configuration module is flexible configuration, is not affected by external profile.
The configuration program is also flexible control.

The idea is to be able to evidence, used and nginx mysql students know, nginx, mysql these programs can be freely specified user configuration.

Therefore, the code should not be directly import confused profile. Above directory structure conf.py, a sample configuration is given, not hard-coded configuration files directly referenced in the program. You can give main.pyto let the program read the contents of the specified configuration path configuration startup parameters way. Of course, where conf.pyyou can change a similar name, for example settings.py. Or you can use the content in other formats to write configuration files, such settings.yamllike.

About main.py

__name__ == '__main__'Python is the main函数inlet. Not to say, adding the phrase to use python xxx.pyto perform, but that, where you can judge whether the current is directly called directly execute python.

getoptIs a packaging method for reading main函数parameters follow later. getopt.getopt(args, options[, long_options])There are three variables, args is the python xxx.pyfollow behind parameters, usually the sys.argvarray, but we will generally remove the first element, because sys.argvthe first element is 文件名itself. Therefore, our wording is sys.argv[1:].

optionsIs a string that describes which parameters need to be resolved. If a parameter is not required with variables, such as -h, the direct use of parameter name. If you need to pass a parameter variable is behind the increase :, for example n:. So in this case hn:w:mean, we have three parameters, namely -h, -n, -wwhich -hdo not need to pass in variable, but -n, -wneed to pass variables.

long_optionsIs an array of strings, which parameters need to parse said. long_optionsIs a relative optionsterms, we are in linux, we often see the parameters of a command are a variety of writing, the most common is to help parameters, it has two writing: -h, --help. The former is what we are options, while the latter is long_options.

If we have a --help, then long_optionsit is in ['help']. If a parameter you need to pass parameters, for example --name 'Good', then long_optionsin that ['name='], yes, that is one more =.

getopt.getoptReturns a tuple (opts, args), which optsis what we parse out parameters, but argsit is not resolved the remaining parameters. optsIt is an array of tuples, each tuple, corresponds to the key-value. keyIs our parameter name, valueis the content parameters.

Classic example:

# coding=utf-8

import getopt

import sys

if __name__ == '__main__':

opts, args = getopt.getopt(sys.argv[1:], 'hn:w:', ['name=', 'word=', 'help'])

name = 'No Name'

word = 'Hello'

for key, value in opts:

if key in ['-h', '--help']:

print 'a program to a human hello'

print 'parameter:'

print'-h \ t Display help '

print'-n \ t your name '

print'-w \ t want to say '

sys.exit(0)

if key in ['-n', '--name']:

name = value

if key in ['-w', '--word']:

word = value

print 'Hello, my name', name, ',', word

Class class call priority:

1、def__new__(cls):

2、def__init__(self):

3、def__call__(self, x):