python程序应用_Python应用程序布局：参考

python程序应用

Python, though opinionated on syntax and style, is surprisingly flexible when it comes to structuring your applications.

尽管Python在语法和样式方面颇受好评，但在构造应用程序时却异常灵活。

On the one hand, this flexibility is great: it allows different use cases to use structures that are necessary for those use cases. On the other hand, though, it can be very confusing to the new developer.

一方面，这种灵活性非常好：它允许不同的用例使用这些用例所必需的结构。 但是，另一方面，这会使新开发人员感到非常困惑。

The Internet isn’t a lot of help either—there are as many opinions as there are Python blogs. In this article, I want to give you a dependable Python application layout reference guide that you can refer to for the vast majority of your use cases.

互联网也无济于事-意见与Python博客一样多。 在本文中，我想为您提供可靠的Python应用程序布局参考指南，您可以在绝大多数用例中参考该指南 。

You’ll see examples of common Python application structures, including command-line applications (CLI apps), one-off scripts, installable packages, and web application layouts with popular frameworks like Flask and Django.

您将看到常见Python应用程序结构的示例，包括命令行应用程序（CLI应用程序），一次性脚本，可安装软件包以及带有流行框架（例如Flask和Django）的 Web应用程序布局。

Note: This reference guide assumes a working knowledge of Python modules and packages. Check out our introduction to Python modules and packages for a refresher if you’re feeling a little rusty.

注意：本参考指南假定您对Python模块和软件包有一定的了解。 如果您感到有些生锈，请查看我们对Python模块和软件包的介绍 ，以复习一下。

命令行应用程序布局 (Command-Line Application Layouts)

A lot of us work primarily with Python applications that are run via command-line interfaces (CLIs). This is where you often start with a blank canvas, and the flexibility of Python application layouts can be a real headache.

我们很多人主要使用通过命令行界面（CLI）运行的Python应用程序。 这是您通常从空白画布开始的地方，Python应用程序布局的灵活性可能真是令人头疼。

Starting with an empty project folder can be intimidating and lead to no shortage of coder’s block. In this section, I want to share some proven layouts that I personally use as a starting point for all of my Python CLI applications.

从一个空的项目文件夹开始可能会令人生畏，并且会导致缺少编码器块。 在本部分中，我想分享一些经过验证的布局，这些布局我个人用作所有Python CLI应用程序的起点。

We’ll start with a very basic layout for a very basic use case: a simple script that runs on its own. You’ll then see how to build up the layout as the use cases advance.

我们将从一个非常基本的用例的非常基本的布局开始：一个独立运行的简单脚本。 然后，您将了解如何随着用例的发展而构建布局。

一次性脚本 (One-Off Script)

You just make a .py script, and it’s gravy, right? No need to install—just run the script in its directory!

您只需创建一个.py脚本，它就很肉汁了，对吗？ 无需安装-只需在其目录中运行脚本即可！

Well, that’s fine if you’re just making a script for your own use, or one that doesn’t have any external dependencies, but what if you have to distribute it? Especially to a less tech-savvy user?

好吧，如果您只是编写一个供自己使用的脚本，或者没有任何外部依赖性的脚本，那很好，但是如果您必须分发该脚本呢？ 尤其是对于不那么精通技术的用户？

The following layout will work for all of these cases and can easily be modified to reflect whatever installation or other tools you use in your workflow. This layout will cover you whether you’re creating a pure Python script (that is, one with no dependencies) or using a tool like pip or Pipenv.

以下布局将适用于所有这些情况，并且可以轻松修改以反映您在工作流程中使用的任何安装或其他工具。 无论您是要创建纯Python脚本（即无依赖性的脚本）还是使用pip或Pipenv之类的工具，这种布局都将覆盖您。

While you read this reference guide, keep in mind that the exact location of the files in the layout matters less than the reason they are placed where they are. All of these files should be in a project directory named after your project. For this example, we will use (what else?) helloworld as the project name and root directory.

阅读本参考指南时，请记住，文件在布局中的确切位置比其放置位置的原因要少。 所有这些文件都应位于以项目命名的项目目录中。 对于此示例，我们将使用（还有什么？） helloworld作为项目名称和根目录。

Here’s the Python project structure I typically use for a CLI app:

这是我通常用于CLI应用程序的Python项目结构：

helloworld/
│
├── .gitignore
├── helloworld.py
├── LICENSE
├── README.md
├── requirements.txt
├── setup.py
└── tests.py
helloworld/
│
├── .gitignore
├── helloworld.py
├── LICENSE
├── README.md
├── requirements.txt
├── setup.py
└── tests.py

This is pretty straightforward: everything is in the same directory. The files shown here are not necessarily exhaustive, but I recommend keeping the number of files to a minimum if you plan on using a basic layout like this. Some of these files will be new to you, so let’s take a quick look at what each of them does.

这非常简单：所有内容都在同一目录中。 此处显示的文件不一定是详尽无遗的，但是如果您打算使用这种基本布局，则建议将文件数保持在最少。 其中一些文件对您来说是新文件，因此让我们快速看一下每个文件的功能。

• .gitignore: This is a file that tells Git which kinds of files to ignore, like IDE clutter or local configuration files. Our Git tutorial has all the details, and you can find sample .gitignore files for Python projects here.

• helloworld.py: This is the script that you’re distributing. As far as naming the main script file goes, I recommend that you go with the name of your project (which is the same as the name of the top-level directory).

• LICENSE: This plaintext file describes the license you’re using for a project. It’s always a good idea to have one if you’re distributing code. The filename is in all caps by convention.

  Note: Need help selecting a license for your project? Check out ChooseALicense.

• README.md: This is a Markdown (or reStructuredText) file documenting the purpose and usage of your application. Crafting a good README is an art, but you can find a shortcut to mastery here.

• requirements.txt: This file defines outside Python dependencies and their versions for your application.

• setup.py: This file can also be used to define dependencies, but it really shines for other work that needs to be done during installation. You can read more about both setup.py and requirements.txt in our guide to Pipenv.

• tests.py: This script houses your tests, if you have any. You should have some.

• .gitignore ：这是一个文件，告诉Git忽略哪些文件，例如IDE混乱文件或本地配置文件。 我们的Git教程包含所有详细信息 ，您可以在此处找到Python项目的示例.gitignore文件。

• helloworld.py ：这是您要分发的脚本。 就命名主脚本文件而言，建议您使用项目名称（与顶级目录的名称相同）。

• LICENSE ：此纯文本文件描述了您用于项目的许可证。 如果您要分发代码，最好有一个。 文件名按惯例大写。

  注意：需要帮助为您的项目选择许可证吗？ 查看ChooseALicense 。

• README.md ：这是一个Markdown （或reStructuredText ）文件，记录了应用程序的用途和用途。 编写优秀的README是一门艺术，但是您可以在这里找到精通的捷径。

• requirements.txt ：此文件为您的应用程序定义外部Python依赖关系及其版本。

• setup.py ：该文件也可以用来定义依赖关系，但是对于在安装过程中需要完成的其他工作来说确实很有帮助。 您可以在Pipenv指南中阅读有关setup.py和requirements.txt更多信息。

• tests.py ：如果有测试，此脚本将存储您的测试。 你应该有一些。

But now that your application is growing, and you’ve broken it out into multiple pieces within the same package, should you keep all pieces in the top-level directory? Now that your application is more complex, it’s time to organize things more cleanly.

但是，既然您的应用程序正在增长，并且已将其分解为同一软件包中的多个部分，是否应该将所有部分都保留在顶层目录中？ 现在您的应用程序更加复杂，是时候更整洁地组织事情了。

可安装的单个包装 (Installable Single Package)

Let’s imagine that helloworld.py is still the main script to execute, but you’ve moved all helper methods to a new file called helpers.py.

假设helloworld.py仍然是要执行的主要脚本，但是您已经将所有辅助方法移到了一个名为helpers.py的新文件中。

We are going to package the helloworld Python files together but keep all the miscellaneous files, such as your README, .gitignore, and so on, at the top directory.

我们将把helloworld Python文件打包在一起，但将所有其他文件（例如README ， .gitignore等）保留在顶部目录中。

Let’s take a look at the updated structure:

让我们看一下更新后的结构：

The only difference here is that your application code is now all held in the helloworld subdirectory—this directory is named after your package—and that we’ve added a file called __init__.py. Let’s introduce these new files:

唯一的区别是您的应用程序代码现在全部保存在helloworld子目录中（此目录以您的软件包命名），并且我们添加了一个名为__init__.py的文件。 让我们介绍这些新文件：

• helloworld/__init__.py: This file has many functions, but for our purposes it tells the Python interpreter that this directory is a package directory. You can set up this __init__.py file in a way that enables you to import classes and methods from the package as a whole, instead of knowing the internal module structure and importing from helloworld.helloworld or helloworld.helpers.

  Note: For a deeper discussion on internal packages and __init__.py, our Python modules and packages overview has you covered.

• helloworld/helpers.py: As mentioned above, we’ve moved much of helloworld.py’s business logic to this file. Thanks to __init__.py, outside modules will be able to access these helpers simply by importing from the helloworld package.

• tests/: We’ve moved our tests into their own directory, a pattern you’ll continue to see as our program structures gain complexity. We have also split our tests into separate modules, mirroring our package’s structure.

• helloworld/__init__.py ：此文件具有许多功能，但出于我们的目的，它告诉Python解释器此目录是程序包目录。 您可以通过以下方式设置此__init__.py文件，该方法使您可以从整个包中导入类和方法，而无需了解内部模块结构并从helloworld.helloworld或helloworld.helpers导入。

  注意：有关内部软件包和__init__.py的更深入讨论， 我们介绍了Python模块和软件包概述 。

• helloworld/helpers.py ：如上所述，我们已将helloworld.py的许多业务逻辑移至该文件。 多亏了__init__.py ，外部模块可以轻松地通过从helloworld包中导入来访问这些帮助器。

• tests/ ：我们已经将测试移到了自己的目录中，随着我们的程序结构变得越来越复杂，您将继续看到这种模式。 我们还将测试分为单独的模块，以反映我们包的结构。

This layout is a stripped down version of Kenneth Reitz’s samplemod application structure. It is another great starting point for your CLI applications, especially for more expansive projects.

此布局是Kenneth Reitz的samplemod应用程序结构的简化版本。 对于您的CLI应用程序，这是另一个很好的起点，尤其是对于更广泛的项目。

内部包装申请 (Application with Internal Packages)

In larger applications, you may have one or more internal packages that are either tied together with a main runner script or that provide specific functionality to a larger library you are packaging. We will extend the conventions laid out above to accommodate for this:

在较大的应用程序中，您可能具有一个或多个内部软件包，这些内部软件包与主运行程序脚本捆绑在一起，或者为要打包的较大库提供特定功能。 我们将扩展上面列出的约定以适应以下情况：

helloworld/
│
├── bin/
│
├── docs/
│   ├── hello.md
│   └── world.md
│
├── helloworld/
│   ├── __init__.py
│   ├── runner.py
│   ├── hello/
│   │   ├── __init__.py
│   │   ├── hello.py
│   │   └── helpers.py
│   │
│   └── world/
│       ├── __init__.py
│       ├── helpers.py
│       └── world.py
│
├── data/
│   ├── input.csv
│   └── output.xlsx
│
├── tests/
│   ├── hello
│   │   ├── helpers_tests.py
│   │   └── hello_tests.py
│   │
│   └── world/
│       ├── helpers_tests.py
│       └── world_tests.py
│
├── .gitignore
├── LICENSE
└── README.md
helloworld/
│
├── bin/
│
├── docs/
│   ├── hello.md
│   └── world.md
│
├── helloworld/
│   ├── __init__.py
│   ├── runner.py
│   ├── hello/
│   │   ├── __init__.py
│   │   ├── hello.py
│   │   └── helpers.py
│   │
│   └── world/
│       ├── __init__.py
│       ├── helpers.py
│       └── world.py
│
├── data/
│   ├── input.csv
│   └── output.xlsx
│
├── tests/
│   ├── hello
│   │   ├── helpers_tests.py
│   │   └── hello_tests.py
│   │
│   └── world/
│       ├── helpers_tests.py
│       └── world_tests.py
│
├── .gitignore
├── LICENSE
└── README.md

There’s a bit more to digest here, but as long as you remember that it follows from the previous layout, you will have an easier time following along. I’ll go through the additions and modifications in order, their uses, and the reasons you might want them.

这里还有更多需要消化的地方，但是只要您记住它是按照以前的布局进行的，那么接下来的时间就会更加轻松。 我将按顺序介绍添加和修改，它们的使用以及您可能需要它们的原因。

• bin/: This directory holds any executable files. I’ve adapted this from Jean-Paul Calderone’s classic structure post, and his prescriptions for the use of a bin/ directory are still important. The most important point to remember is that your executable shouldn’t have a lot of code, just an import and a call to a main function in your runner script. If you are using pure Python or don’t have any executable files, you can leave out this directory.

• /docs: With a more advanced application, you’ll want to maintain good documentation of all its parts. I like to put any documentation for internal modules here, which is why you see separate documents for the hello and world packages. If you use docstrings in your internal modules (and you should!), your whole-module documentation should at the very least give a holistic view of the purpose and function of the module.

• helloworld/: This is similar to helloworld/ in the previous structure, but now there are subdirectories. As you add more complexity, you’ll want to use a “divide and conquer” tactic and split out parts of your application logic into more manageable chunks. Remember that the directory name refers to the overall package name, and so the subdirectory names (hello/ and world/) should reflect their package names.

• data/: Having this directory is helpful for testing. It’s a central location for any files that your application will ingest or produce. Depending on how you deploy your application, you can keep “production-level” inputs and outputs pointed to this directory, or only use it for internal testing.

• tests/: Here, you can put all your tests—unit tests, execution tests, integration tests, and so on. Feel free to structure this directory in the most convenient way for your testing strategies, import strategies, and more. For a refresher on testing command-line applications with Python, check out my article 4 Techniques for Testing Python Command-Line (CLI) Apps.

• bin/ ：此目录包含所有可执行文件。 我改编自Jean-Paul Calderone的经典结构文章 ，并且他使用bin/目录的处方仍然很重要。 要记住的最重要的一点是，您的可执行文件应该没有太多的代码，而仅仅是运行程序脚本中的导入和对主函数的调用。 如果您使用的是纯Python或没有任何可执行文件，则可以忽略此目录。

• /docs ：使用更高级的应用程序，您将需要维护其所有部分的良好文档。 我喜欢在这里放置内部模块的所有文档，这就是为什么您会看到hello和world软件包的单独文档的原因。 如果在内部模块中使用文档字符串（并且应该这样做！），则整个模块的文档至少应提供模块目的和功能的整体视图。

• helloworld/ ：这与以前的结构中的helloworld/相似，但是现在有子目录。 随着复杂性的增加，您将需要使用“分而治之”的策略，将应用程序逻辑的各个部分分成更易于管理的块。 请记住，目录名称是指整个软件包的名称，因此子目录名称（ hello/和world/ ）应反映其软件包名称。

• data/ ：拥有此目录有助于测试。 它是应用程序将提取或产生的任何文件的中央位置。 根据部署应用程序的方式，可以将“生产级别”的输入和输出保持指向该目录，或仅将其用于内部测试。

• tests/ ：您可以在这里放置所有测试-单元测试，执行测试，集成测试等。 随意以最方便的方式为您的测试策略，导入策略等构建此目录。 有关使用Python测试命令行应用程序的复习，请参阅我的文章4测试Python命令行（CLI）应用程序的技术 。

The top-level files remain largely the same as in the previous layout. These three layouts should cover most use cases for command-line applications, and even GUI applications with the caveat that you may have to tinker with some things depending on the GUI framework you use.

顶级文件与以前的布局基本相同。 这三种布局应涵盖大多数命令行应用程序用例，甚至包括GUI应用程序，但要注意的是，您可能需要根据所使用的GUI框架进行一些修改。

Note: Keep in mind that these are just layouts. If a directory or file doesn’t make sense for your specific use case (like tests/ if you aren’t distributing tests with your code), feel free to leave it out. But try not to leave out docs/. It’s always a good idea to document your work.

注意：请记住，这些只是布局。 如果目录或文件对您的特定用例没有意义（例如tests/如果您不使用代码分发测试），请随时将其忽略。 但是，请尽量不要遗漏docs/ 。 记录您的工作始终是一个好主意。

Web应用程序布局 (Web Application Layouts)

Another major use case of Python is web applications. Django and Flask are arguably the most popular web frameworks for Python and thankfully are a little more opinionated when it comes to application layout.

Python的另一个主要用例是Web应用程序。 Django和Flask可以说是最受欢迎的Python Web框架，而且值得庆幸的是，在应用程序布局方面，他们的看法也有所不同。

In order to make sure this article is a complete, full-fledged layout reference, I wanted to highlight the structure common to these frameworks.

为了确保本文是完整的，完整的布局参考，我想强调这些框架共有的结构。

Django的 (Django)

Let’s go in alphabetical order and start with Django. One of the nice things about Django is that it will create a project skeleton for you after running django-admin startproject project, where project is the name of your project. This will create a directory in your current working directory called project with the following internal structure:

让我们按字母顺序进行，从Django开始。 Django的优点之一是，它将在运行django-admin startproject project后为您创建一个项目框架，其中project是project的名称。 这将在您当前的工作目录中创建一个名为project目录，该目录具有以下内部结构：

This seems a little empty, doesn’t it? Where does all the logic go? The views? There aren’t even any tests!

这似乎有些空虚，不是吗？ 所有逻辑都去哪儿了？ 观点？ 甚至没有任何测试！

In Django, this is a project, which ties together the other Django concept, apps. Apps are where logic, models, views, and so on all live, and in doing so they do some task, such as maintaining a blog.

在Django中，这是一个项目，将其他Django概念（应用程序）联系在一起。 应用程序是逻辑，模型，视图等全部实时存在的地方，并且在执行过程中它们会执行某些任务，例如维护博客。

Django apps can be imported into projects and used across projects, and are structured like specialized Python packages.

Django应用程序可以导入到项目中并在项目中使用，其结构类似于专用的Python包。

Like projects, Django makes generating Django app layouts really easy. After you set up your project, all you have to do is navigate to the location of manage.py and run python manage.py startapp app, where app is the name of your app.

像项目一样，Django使生成Django应用布局非常容易。 设置项目后，您要做的就是导航到manage.py的位置并运行python manage.py startapp app ，其中app是您的应用程序的名称。

This will result in a directory called app with the following layout:

这将导致名为app的目录具有以下布局：

app/
│
├── migrations/
│   └── __init__.py
│
├── __init__.py
├── admin.py
├── apps.py
├── models.py
├── tests.py
└── views.py
app/
│
├── migrations/
│   └── __init__.py
│
├── __init__.py
├── admin.py
├── apps.py
├── models.py
├── tests.py
└── views.py

This can then be imported directly into your project. Details on what these files do, how to harness them for your project, and so forth are outside the scope of this reference, but you can get all that information and more in our Django tutorial and also in the official Django docs.

然后可以将其直接导入到您的项目中。 这些文件的功能，如何为您的项目利用它们的细节等等不在本参考文献的讨论范围之内，但是您可以在我们的Django教程和官方Django文档中获得所有这些信息以及更多信息。

This file and folder structure is very barebones and the basic requirements for Django. For any open-source Django project, you can (and should) adapt the structures from the command-line application layouts. I typically end up with something like this in the outer project/ directory:

这个文件和文件夹的结构是准系统，是Django的基本要求。 对于任何开源Django项目，您都可以（并且应该）从命令行应用程序布局中调整结构。 我通常在外部project/目录中得到如下所示的结果：

For a deeper discussion on more advanced Django application layouts, this Stack Overflow thread has you covered. The django-project-skeleton project documentation explains some of the directories you will find in the Stack Overflow thread. A comprehensive dive into Django can be found in the pages of Two Scoops of Django, which will teach you all of the latest best practices for Django development.

要更深入地讨论更高级的Django应用程序布局，请参见本Stack Overflow主题 。 django-project-skeleton项目文档介绍了一些在Stack Overflow线程中找到的目录。 可以在Django的两个独家摘要页面中找到有关Django的全面介绍 ，该课程将教您所有有关Django开发的最新最佳实践。

For more Django tutorials, visit our Django section at Real Python.

有关更多Django教程， 请访问Real Python上的Django部分 。

烧瓶 (Flask)

Flask is a Python web “microframework.” One of the main selling points is that it is very quick to set up with minimal overhead. The Flask documentation has a web application example that’s under 10 lines of code and in a single script. Of course, in practice, it’s highly unlikely you’ll be writing a web application this small.

Flask是Python网络上的“微框架”。 主要卖点之一是设置非常快，开销最小。 Flask文档提供了一个Web应用程序示例，该示例使用10行代码并在一个脚本中。 当然，在实践中，编写这样小的Web应用程序的可能性很小。

Luckily, the Flask documentation swoops in to save us with a suggested layout for their tutorial project (a blogging web application called Flaskr), and we will examine that here from within the main project directory:

幸运的是，Flask文档大量涌入，为我们的教程项目（名为Flaskr的博客Web应用程序）提供了建议的布局，我们将在此处从主项目目录中进行检查：

flaskr/
│
├── flaskr/
│   ├── ___init__.py
│   ├── db.py
│   ├── schema.sql
│   ├── auth.py
│   ├── blog.py
│   ├── templates/
│   │   ├── base.html
│   │   ├── auth/
│   │   │   ├── login.html
│   │   │   └── register.html
│   │   │
│   │   └── blog/
│   │       ├── create.html
│   │       ├── index.html
│   │       └── update.html
│   │ 
│   └── static/
│       └── style.css
│
├── tests/
│   ├── conftest.py
│   ├── data.sql
│   ├── test_factory.py
│   ├── test_db.py
│   ├── test_auth.py
│   └── test_blog.py
│
├── venv/
│
├── .gitignore
├── setup.py
└── MANIFEST.in
flaskr/
│
├── flaskr/
│   ├── ___init__.py
│   ├── db.py
│   ├── schema.sql
│   ├── auth.py
│   ├── blog.py
│   ├── templates/
│   │   ├── base.html
│   │   ├── auth/
│   │   │   ├── login.html
│   │   │   └── register.html
│   │   │
│   │   └── blog/
│   │       ├── create.html
│   │       ├── index.html
│   │       └── update.html
│   │ 
│   └── static/
│       └── style.css
│
├── tests/
│   ├── conftest.py
│   ├── data.sql
│   ├── test_factory.py
│   ├── test_db.py
│   ├── test_auth.py
│   └── test_blog.py
│
├── venv/
│
├── .gitignore
├── setup.py
└── MANIFEST.in

From these contents, we can see that a Flask application, like most Python applications, is built around Python packages.

从这些内容中，我们可以看到Flask应用程序与大多数Python应用程序一样，都是围绕Python包构建的。

Note: Not seeing it? A quick tip for spotting packages is by looking for an __init__.py file. This sits in the highest-level directory for that particular package. In the above layout, flaskr is a package containing the db, auth, and blog modules.

注意：看不到吗？ 查找包的快速提示是查找__init__.py文件。 它位于该特定软件包的最高目录中。 在上述布局中， flaskr是一个包含db ， auth和blog模块的软件包。

In this layout, everything lives in the flaskr package except for your tests, a directory for your virtual environments, and your usual top-level files. As in other layouts, your tests will roughly match the individual modules residing within the flaskr package. Your templates also reside in the main project package, which would not happen with the Django layouts.

在这种布局中，除了测试， 虚拟环境的目录以及通常的顶级文件以外，所有内容都保存在flaskr软件包中。 与其他布局一样，您的测试将大致匹配flaskr软件包中的各个模块。 您的模板也位于主项目包中，而Django布局则不会发生。

Be sure to also visit our Flask Boilerplate Github page for a view of a more fully fleshed-out Flask application and see the boilerplate in action here.

请确保也访问我们的Flask Boilerplate Github页面 ，以查看更加完善的Flask应用程序，并在此处查看实际的样板。

For more on Flask, check out all of our Flask tutorials here.

有关Flask的更多信息， 请在此处查看我们所有的Flask教程 。

结论与提醒 (Conclusions and Reminders)

Now you’ve seen example layouts for a number of different application types: one-off Python scripts, installable single packages, larger applications with internal packages, Django web applications, and Flask web applications.

现在，您已经看到了许多不同应用程序类型的示例布局：一次性Python脚本，可安装的单个程序包，带有内部程序包的较大应用程序，Django Web应用程序和Flask Web应用程序。

Coming away from this guide, you will have the tools to successfully prevent coder’s block by building out your application structure so that you’re not staring at a blank canvas trying to figure out where to start.

远离本指南，您将拥有通过构建应用程序结构来成功防止编码器阻塞的工具，从而无需盯着空白画布来试图从哪里开始。

Because Python is largely non-opinionated when it comes to application layouts, you can customize these example layouts to your heart’s content to better fit your use case.

因为在应用程序布局方面，Python在很大程度上是不受人欢迎的，所以您可以根据自己的意愿自定义这些示例布局，以更好地适应您的用例。

I want you to not only have an application layout reference but also come away with the understanding that these examples are neither hard-and-fast rules nor the only way to structure your application. Over time and with practice, you’ll develop the ability to build and customize your own useful Python application layouts.

我希望您不仅有一个应用程序布局参考，而且还希望您理解这些示例既不是严格的规则，也不是构造应用程序的唯一方法。 随着时间的推移和实践，您将开发出构建和定制自己有用的Python应用程序布局的功能。

Did I miss a use case? Do you have another application structure philosophy? Did this article help prevent coder’s block? Let me know in the comments!

我错过了用例吗？ 您还有另一种应用程序结构哲学吗？ 本文是否有助于防止编码器阻塞？ 在评论中让我知道！

翻译自: https://www.pybloggers.com/2018/06/python-application-layouts-a-reference/

python程序应用