如何在（相对）大项目中组织Python文件 [英] How to organize Python files in a (relatively) big project
问题描述
你好，
我已经编写了一段时间的python，现在。但是当我开始做更复杂的事情时，我正在遇到小组织
问题。
我想要的可能是什么获得是不可能的，但我会像更多经验丰富的python程序员的建议那样b $ b。
我在python中编写一个相对复杂的程序围绕
40个文件。
起初，我把所有文件放在一个目录中，但是现在，随着
的增加，文件，浏览我的目录变得很难。
所以，我希望能够根据目的在8个目录，
之间划分文件。问题是它打破了我的文件之间的导入
。除了AFAIK之外，没有简单的方法可以导入不在当前文件子目录中的
文件（我想我可以调整os.path
在每个文件中，但这似乎不是很优雅
给我）。
我想把整个变成一个包。但我必须将每个''import module_name''更改为
''从package_name.sub_directory_name import module_name''
这是一个有点耗时并且不够灵活（如果我改变了一个文件所属的子目录，我将不得不再次跟踪
每次导入以纠正它们）
所以，基本上，这就是重点：是否有'优雅'的方式将我的
文件保存在单独的目录中仍然能够在他们之间导入
简单的''import filename''？
如果没有，那将是组织无数python的标准方法
属于同一个项目的文件？
谢谢，
TokiDoki
我自己也有这个问题，因为我是最近的Python转换我的
aproach可能不是常规的 - 但是因为它对我有用我认为
我会分享。
首先，您需要将代码拆分为逻辑对象。在我的情况下
我有一个明显的客户端和服务器对象，但在每个我有
个人独立主要对象，所以我的目录结构
反映了这个...
Prog Dir
- MainApp.py
Bin
__init__.py
--- main.py
--- lib.py
客户
__init__。 py
--- main.py
浏览器1
__init__.py
--- main.py
--- B1_file1.py
--- B1_file2.py
浏览器2
__init __。py
--- main.py
--- B2_file1.py
--- B2_file2.py
服务器
__init__.py
--- main.py
服务器对象1
__init __。py
--- main.py
--- SO1_file1.py
--- SO1_file2.py
服务器对象2
__init__.py
--- main.py
--- SO2_file1.py
--- SO2_file2.py
每个main.py文件用于c所有每个下游的main.py文件都是
一个线程或只运行一次。这个想法的美妙之处在于，如果我想要完全改变说服务器对象2，我可以做任何我喜欢的事情
在下游目录中作为唯一的外部呼叫是通过
对main.py文件的外部引用。
如果您有意，可以拥有常用应用程序的库文件 bin目录中的
，你可以将它们提供给所有下游的
模块。
正如我所说 - 只有你可以逻辑地工作将您的计划分成
独立区块。
如果有更多Pythonesque方式这样做我很感激如果
某人可以分享。
HTH
TokiDoki写道：
起初，我将所有文件放在一个目录中，但是现在，随着文件数量的增加，浏览我的目录变得越来越困难。所以，我希望能够根据目的在8个目录之间划分文件。问题是它打破了我的文件之间的导入。而且，AFAIK，没有简单的方法来导入不在当前文件的子目录中的文件
请记住启动顶级脚本的目录始终包含在sys.path中。
。这意味着你可以拥有像
这样的结构：
main.py
|
| - - pkg1
| - - pkg2
| - - pkg3
任何包中的文件都可以导入其他包。通常的做法是输入
pkgN。然后解除引用。在每个包中，你将有一个__init__.py
，它将定义包API（也就是说，将定义你可以从包外访问的那些符号） 。
通常，您只想导入* packages *，而不是子模块。换句话说，
尝试不做来自pkg1.submodule3 import Foo之类的东西，因为这会打破
封装（如果你重新组织pkg1的结构，代码会打破）。所以
你会做导入pgk1假设pkg1.__init__.py
执行from submodule3 import Foo之类的操作，后来称为pkg1.Foo。我的首选方法是让
__init__.py只做来自子模块导入*，然后每个子模块定义
__all__来指定它的公共符号。这允许更多的b $ b封装（每个子模块能够以
自包含的方式更改它导出的内容，你也不需要修改__init__） 。
此外，包之间的依赖图不应该有循环。对于
实例，如果pkg3使用pkg1，则pkg1不应该使用pkg3。将pkg1的
视为pkg3使用的库的道德等价物是有道理的。
-
Giovanni Bajo
如果我理解你，你需要一个概念，你可以在其中放置项目的文件
，即重构目录的嵌套
存储你的脚本没有破坏导入语句的问题。
这将使你无法解决任何你可能遇到的问题
管理一个大包装，但本身就是一个问题，所以我看到你有大量的选择可供选择：
1.最好是你得到的一个更好的项目结构在你的脑海中，所以你不需要经常更改你的模块到各种
目录（平板比嵌套更好） 。在将它分成两个单独的文件之前，设置一个必须达到的单个
Python脚本的大小限制，所以
你的文件数减少到一个你可以的数字轻松处理
（这取决于你有多好）。
2.创建例如一个HTML文件，您可以从中查看，编辑，执行您拥有的
脚本。在此文件中，您可以创建嵌套结构，并以这种方式获得所需的概述
。 Python文件保留在一个目录中
存储整个项目。这允许你将属于
的东西放在一起，但是要使用它，因为单个文件分布在许多
类别（我的意思是目录:)。
3.创建一个Python脚本，自动创建一个HTML文件，给你
你的所有脚本的概述来自你的目录。
项目文件存储在下面，并在每个脚本中放入一个函数
，它在调用时返回文件传递名称的实际完整路径
import并更新Python路径，以便它可以找到（例如
updatePATH（''nameOfTheModuleToImport''）
4.开始从许多项目管理工具中选择将保持
您忙碌一段时间而远离项目的实际工作......
以上这些都不能解决所谓的实际问题，该项目
超出了管理它的能力。我知道这个李mitation
我看到程序员在项目中失败了，他们的规模越来越大。通常，大型项目中单个模块之间的依赖关系变得越来越复杂。每个下一个添加的模块使得项目更大的b
必须与整个已经存在的模块一起使用，并且在达到给定项目大小的b / b $ b后，它变得非常困难（对于某些人来说）只是
不可能）为它添加一个新模块，对现有的模块进行必要的修改以获得新的功能。这些修改
通常会导致项目其他部分的中断，而在我看来，没有
管理系统可以真正帮助预测它。每个
程序员似乎都有一个他可以管理的项目规模的限制，并且在我的意见中没有用于构建它或获得更好的概述的工具是真正的
帮助到这里。问题的核心是缺乏管理大型项目所需的技能，而且似乎并非所有能够学会了b
计划的人都能够获得必要的技能。通过他的智力限制来增加一个项目的规模。这就是为什么
程序员需要团队合作并且有一个非常优秀的经理能够协调他们的努力才能成功创建大型应用程序。
在非常大的项目中，有时需要在现有的代码库上工作半年或者更多的全部时间才能获得
写一行代码另外一个。
发布你的代码，让其他人使用它，尝试获得它的响应和
你可能会从这里得到更多而不是要求管理它的方式。
如果这个新闻组中的其他人同意我上面所说的话，我很好奇，所以我
很高兴听到它。
Claudio
" TokiDoki" <是ne ********* @ wanadoo.fr> schrieb im Newsbeitrag
新闻：dj ********** @ apollon.grec.isp.9tel.net ...你好，
我已经编写了一段时间的python，现在。但是当我开始做更复杂的事情时，我遇到了小组织问题。
有可能我想要获得的东西是不可能的，但我会
喜欢更有经验的python程序员的建议。
我正在python中编写一个相对复杂的程序，现在有40个文件。
起初，我拥有了所有的文件在一个目录中，但是现在，随着文件数量的增加，浏览我的
目录变得越来越困难。所以，我希望能够根据目的在8个目录之间划分文件。问题是它打破了我的文件之间的导入。而且，AFAIK，没有简单的方法来导入不在当前文件的子目录中的文件（我想我可以调整每个文件中的os.path，但这似乎不是非常优雅对我来说。
我想把整个变成一个包。但我必须从package_name.sub_directory_name import module_name''
将每个''import module_name''更改为
''，这有点费时并且不够灵活（如果我更改）
我对一个文件属于的子目录的想法，我将不得不再次跟踪
每次导入以纠正它们。
所以，基本上，这里有一点：是否存在优雅的方式将我的
文件保存在单独的目录中，并且仍然能够在它们之间导入
简单的''import filename''？
如果没有，组织属于同一项目的众多python文件的标准方法是什么？
谢谢，
TokiDoki
Hello there,
I have been programming python for a little while, now. But as I am
beginning to do more complex stuff, I am running into small organization
problems.
It is possible that what I want to obtain is not possible, but I would
like the advice of more experienced python programmers.
I am writing a relatively complex program in python that has now around
40 files.
At first, I had all of my files in one single directory, but now, with
the increasing number of files, it is becoming hard to browse my directory.
So, I would want to be able to divide the files between 8 directory,
according to their purpose. The problem is that it breaks the ''import''s
between my files. And besides,AFAIK, there is no easy way to import a
file that is not in a subdirectory of the current file (I suppose I
could adjust the os.path in every file, but that seems not very elegant
to me).
I thought about turning the whole into a package. But I have to change
every ''import module_name'' into
''from package_name.sub_directory_name import module_name''
which is a little bit time consuming and not very flexible (if I change
my mind about the subdirectory a file belongs to, I will have to track
again every import to correct them)
So, basically, here is the point: is there an ''elegant'' way to keep my
files in separate directory and still be able to import between them
with simple ''import filename''?
And if not, what would be the standard way to organize numerous python
files belonging to the same project?
Thank you,
TokiDoki
I have this problem myself, and as I am a recent Python convert my
aproach may not be conventional - but as it is working for me I thought
I would share.
First off you need to split your code into logical objects. In my case
I have an obvious client and server object, But within each I have
individual stand alone major objects and so my directory structure
reflects this...
Prog Dir
-- MainApp.py
Bin
__init__.py
--- main.py
--- lib.py
Client
__init__.py
--- main.py
Browser 1
__init__.py
--- main.py
--- B1_file1.py
--- B1_file2.py
Browser 2
__init__.py
--- main.py
--- B2_file1.py
--- B2_file2.py
Server
__init__.py
--- main.py
Server Object 1
__init__.py
--- main.py
--- SO1_file1.py
--- SO1_file2.py
Server Object 2
__init__.py
--- main.py
--- SO2_file1.py
--- SO2_file2.py
Each main.py file is used to call each downstream main.py file be it as
a thread or once only run. The beauty of this idea is that if I want
to completely change say Server Object 2, I can do whatever I like
within the downstream directory as the only outside call is via an
external reference to the main.py file.
If you have a mind, you could have a library file of common apps held
within the bin directory that you can make available to all downstream
modules.
As I say - it only works if you can logically split your program into
independent blocks.
If there is a more Pythonesque way of doing this I be grateful if
someone could share.
HTH
TokiDoki wrote:
At first, I had all of my files in one single directory, but now, with
the increasing number of files, it is becoming hard to browse my
directory. So, I would want to be able to divide the files between 8
directory, according to their purpose. The problem is that it breaks
the ''import''s between my files. And besides,AFAIK, there is no
easy way to import a
file that is not in a subdirectory of the current file
Remember that the directory where you start the toplevel script is always
included in the sys.path. This means that you can have your structure like
this:
main.py
|
| - - pkg1
| - - pkg2
| - - pkg3
Files in any package can import other packages. The usual way is to do "import
pkgN" and then dereference. Within each package, you will have a __init__.py
which will define the package API (that is, will define those symbols that you
can access from outside the package).
Typically, you only want to import *packages*, not submodules. In other words,
try to not do stuff like "from pkg1.submodule3 import Foo", because this breaks
encapsulation (if you reorganize the structure of pkg1, code will break). So
you''d do "import pgk1" and later "pkg1.Foo", assuming that pkg1.__init__.py
does something like "from submodule3 import Foo". My preferred way is to have
__init__.py just do "from submodules import *", and then each submodule defines
__all__ to specify which are its public symbols. This allow for more
encapsulation (each submodule is able to change what it exports in a
self-contained way, you don''t need to modify __init__ as well).
Moreover, the dependence graph between packages shouldn''t have loops. For
instance, if pkg3 uses pkg1, pkg1 shouldn''t use pkg3. It makes sense to think
of pkg1 as the moral equivalent of a library, which pkg3 uses.
--
Giovanni Bajo
If I understand you right you need a concept in which you can put the files
of your project where you want, i.e. restructure the nesting of directories
storing your scripts without the problem of breaking the import statements.
This will give you not a solution to any problem you maybe have with
managing a large package but is a problem in itself, so I see that you have
a huge number of options to choose from:
1. best is you get a better structure of the project in your mind, so you
don''t need frequent changes by resorting your modules into a various
directories (flat is better than nested). Set a size limit of a single
Python script it must reach before you split it into two separate files, so
that the number of your files decreases to a number you can handle with ease
(this depends on how good you are at it).
2. create e.g. an HTML file from which you can view, edit, execute the
scripts you have. In this file you create your nested structure and have
this way the overview you need. The Python files remain in one directory
storing the entire project. This allows you to keep together what belongs
together, but to work with it as the single files were spread over many
categories (I mean directories :).
3. create a Python script which automatically creates an HTML file giving
you the overview of all your scripts from walking the directories your
project files are stored below and put in each of your scripts a function
which on call returns the actual full path of passed name of the file to
import and updates the Python PATH, so that it can be found (e.g
updatePATH(''nameOfTheModuleToImport'')
4. start to choose from many tools for project management which will keep
you busy for a while and away from the actual work on your project ...
None of these above can solve the supposed actual problem, that the project
grows beyond the capacity to manage it in mind. I know about this limitation
and I have seen programmers failing on projects with increasing size of
them. Usually the dependencies between the single modules in large projects
get more and more complicated. Each next added module making the project
size larger must work with the entire already existing ones and after a
given size of project is reached it becomes really hard (and for some just
impossible) to add a new module to it making the necessary modifications to
existing ones in order to gain the new functionality. Such modifications
result usually in breaks in other parts of the project and in my eyes no
management system can really help in anticipating it at that point. Every
programmer seems to have a limit of a project size he can manage and in my
opinion no tool for structuring it or getting a better overview is of real
help here. The core of the problem is lack of skills required for managing
large projects and it seems, that not everyone who managed to learn to
program is able to acquire this skills necessary to increase the size of a
project over the by his intellectual capacity given limits. That is why
programmer need to work in teams and have a very good manager able to
coordinate their efforts in order to succeed in creating large applications.
In really large projects it is sometimes necessary to work half a year or
more full time on the existing library of code before becoming capable of
writing a single line of additional one.
Publish your code, let others work with it, try to get responses on it and
you will probably get much more out of this than by asking for ways of
managing it.
I am curious if others on this newsgroup agree with what I said above, so I
would be glad to hear about it.
Claudio
"TokiDoki" <ne*********@wanadoo.fr> schrieb im Newsbeitrag
news:dj**********@apollon.grec.isp.9tel.net...Hello there,
I have been programming python for a little while, now. But as I am
beginning to do more complex stuff, I am running into small organization
problems.
It is possible that what I want to obtain is not possible, but I would
like the advice of more experienced python programmers.
I am writing a relatively complex program in python that has now around
40 files.
At first, I had all of my files in one single directory, but now, with
the increasing number of files, it is becoming hard to browse my directory. So, I would want to be able to divide the files between 8 directory,
according to their purpose. The problem is that it breaks the ''import''s
between my files. And besides,AFAIK, there is no easy way to import a
file that is not in a subdirectory of the current file (I suppose I
could adjust the os.path in every file, but that seems not very elegant
to me).
I thought about turning the whole into a package. But I have to change
every ''import module_name'' into
''from package_name.sub_directory_name import module_name''
which is a little bit time consuming and not very flexible (if I change
my mind about the subdirectory a file belongs to, I will have to track
again every import to correct them)
So, basically, here is the point: is there an ''elegant'' way to keep my
files in separate directory and still be able to import between them
with simple ''import filename''?
And if not, what would be the standard way to organize numerous python
files belonging to the same project?
Thank you,
TokiDoki
这篇关于如何在（相对）大项目中组织Python文件的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
