根据我的经验，这只是一个迭代的问题。把你的数据和代码放在你认为它们应该去的地方。不管怎样，你都有可能是错的。但一旦你对事情会如何发展有了更好的了解，你就能更好地做出这些猜测。

至于扩展源，我们在trunk下有一个Code目录，其中包含python目录和其他各种语言目录。就我个人而言，我更倾向于下次尝试将任何扩展代码放到它自己的存储库中。

说了这么多，我回到我最初的观点:不要把它看得太大。把它放在对你有用的地方。如果你发现某些东西不起作用，它可以(也应该)被改变。

以正确的方式查看Python项目的开源。

让我摘录这篇优秀文章的项目布局部分:

When setting up a project, the layout (or directory structure) is important to get right. A sensible layout means that potential contributors don't have to spend forever hunting for a piece of code; file locations are intuitive. Since we're dealing with an existing project, it means you'll probably need to move some stuff around. Let's start at the top. Most projects have a number of top-level files (like setup.py, README.md, requirements.txt, etc). There are then three directories that every project should have: A docs directory containing project documentation A directory named with the project's name which stores the actual Python package A test directory in one of two places Under the package directory containing test code and resources As a stand-alone top level directory To get a better sense of how your files should be organized, here's a simplified snapshot of the layout for one of my projects, sandman: $ pwd ~/code/sandman $ tree . |- LICENSE |- README.md |- TODO.md |- docs | |-- conf.py | |-- generated | |-- index.rst | |-- installation.rst | |-- modules.rst | |-- quickstart.rst | |-- sandman.rst |- requirements.txt |- sandman | |-- __init__.py | |-- exception.py | |-- model.py | |-- sandman.py | |-- test | |-- models.py | |-- test_sandman.py |- setup.py As you can see, there are some top level files, a docs directory (generated is an empty directory where sphinx will put the generated documentation), a sandman directory, and a test directory under sandman.

这篇由Jean-Paul Calderone撰写的博客文章通常是Freenode上#python的答案。

Filesystem structure of a Python project Do: name the directory something related to your project. For example, if your project is named "Twisted", name the top-level directory for its source files Twisted. When you do releases, you should include a version number suffix: Twisted-2.5. create a directory Twisted/bin and put your executables there, if you have any. Don't give them a .py extension, even if they are Python source files. Don't put any code in them except an import of and call to a main function defined somewhere else in your projects. (Slight wrinkle: since on Windows, the interpreter is selected by the file extension, your Windows users actually do want the .py extension. So, when you package for Windows, you may want to add it. Unfortunately there's no easy distutils trick that I know of to automate this process. Considering that on POSIX the .py extension is a only a wart, whereas on Windows the lack is an actual bug, if your userbase includes Windows users, you may want to opt to just have the .py extension everywhere.) If your project is expressable as a single Python source file, then put it into the directory and name it something related to your project. For example, Twisted/twisted.py. If you need multiple source files, create a package instead (Twisted/twisted/, with an empty Twisted/twisted/__init__.py) and place your source files in it. For example, Twisted/twisted/internet.py. put your unit tests in a sub-package of your package (note - this means that the single Python source file option above was a trick - you always need at least one other file for your unit tests). For example, Twisted/twisted/test/. Of course, make it a package with Twisted/twisted/test/__init__.py. Place tests in files like Twisted/twisted/test/test_internet.py. add Twisted/README and Twisted/setup.py to explain and install your software, respectively, if you're feeling nice. Don't: put your source in a directory called src or lib. This makes it hard to run without installing. put your tests outside of your Python package. This makes it hard to run the tests against an installed version. create a package that only has a __init__.py and then put all your code into __init__.py. Just make a module instead of a package, it's simpler. try to come up with magical hacks to make Python able to import your module or package without having the user add the directory containing it to their import path (either via PYTHONPATH or some other mechanism). You will not correctly handle all cases and users will get angry at you when your software doesn't work in their environment.

不太重要。只要能让你开心就行。没有很多愚蠢的规则，因为Python项目可以很简单。

/scripts或/bin之类的命令行界面 /测试你的测试 /lib为您的c语言库 /doc用于大多数文档 /apidoc用于epydoc生成的API文档。

顶层目录可以包含README, Config等等。

困难的选择是是否使用/src树。Python不像Java或C那样区分/src、/lib和/bin。

由于一些人认为顶级/src目录没有意义，所以顶级目录可以是应用程序的顶级体系结构。

/ foo /酒吧 /巴兹

我建议把所有这些都放在“我的产品名称”目录下。如果你写一个名为quux的应用程序，包含这些东西的目录就叫做/quux。

然后，另一个项目的PYTHONPATH可以包含/path/to/quux/foo来重用quux。foo模块。

在我的例子中，因为我使用Komodo Edit，所以我的IDE cuft是一个. kpf文件。实际上，我将其放在顶级/quux目录中，并忽略将其添加到SVN。

根据我的经验，这只是一个迭代的问题。把你的数据和代码放在你认为它们应该去的地方。不管怎样，你都有可能是错的。但一旦你对事情会如何发展有了更好的了解，你就能更好地做出这些猜测。

至于扩展源，我们在trunk下有一个Code目录，其中包含python目录和其他各种语言目录。就我个人而言，我更倾向于下次尝试将任何扩展代码放到它自己的存储库中。

说了这么多，我回到我最初的观点:不要把它看得太大。把它放在对你有用的地方。如果你发现某些东西不起作用，它可以(也应该)被改变。

非Python数据最好使用setuptools中的package_data支持绑定到Python模块中。我强烈推荐的一件事是使用名称空间包来创建多个项目可以使用的共享名称空间——很像将包放在com.yourcompany.yourproject中的Java约定(并且能够拥有一个共享的com.yourcompany.utils名称空间)。

再分支和合并，如果你使用一个足够好的源代码控制系统，它甚至可以通过重命名来处理合并;芭莎在这方面尤其在行。

与这里的其他一些答案相反，我赞成将src目录作为顶级目录(附带doc和test目录)。文档目录树的特定约定将根据您使用的内容而有所不同;例如，Sphinx有自己的快速入门工具支持的约定。

请，请利用setuptools和pkg_resources;这使得其他项目更容易依赖于您代码的特定版本(如果使用package_data，则可以使用不同的非代码文件同时安装多个版本)。