本文拟从以下几个方面来探讨 Python² 在 Large-scale³ 项目中的一些 应用和实践，内容都是满满的原创经验：

• Python 的项目构建
• Python 的代码编写
• Python 的运行时

Python 的项目构建

新项目的构建要解决的问题如下：

标准化目录结构

一个标准的目录结构有助于项目组成员互相理解，减少沟通成本。由于继承性的需要，实际采用的是 maven 模式。于是一个完整的目录结构是这个样子的：

project-root  ├── pom.xml  └── src      ├── main      │   ├── config              │   ├── python        (注1)      │   ├── rpm-resources (注2)      │   └── scripts       (注3)      └── test          ├── config          ├── features      (注4)          └── python        (注5)

注：

1. 存放 Python 的 Package
2. 存放需打包的同等目录结构
3. 存放 Scriptlet
4. 存放 Lettuce Feature 文件
5. 存放 Python 的 UT 和 FT

它与 GitHub 上标准的 Python 项目（如 Django）不同。后者是纯粹的 Python 包，用于发布 PyPI。而企业闭门开发，需要利用内部的 maven 仓库；同时这里⁴更需要一种混合包，以 Python 实现为主体，有限度集成 Shell 脚本。

模块重用

经过一段时间的演化，project-1 和 project-2 的公用部分被独立出来成为新的 common-libs

git-repo-root   ├── common-libs  ├── project-1  └── project-2

或者项目代码跨越了 git 库

git-repo-1   └── common-libs    git-repo-2  ├── project-1  └── project-2

在不同的构建环境(例如 UserHome 或者 Jenkins-CI Slave)中如何让 project-1 和 project-2 顺利发现 common-libs 并依赖⁵之完成构建？这个问题在 Java 世界里很好解决：假如 common-libs 的产出是 jar 包，

cd common-libs  mvn install (or mvn deploy)  cd ../project-1  mvn deploy  cd ../project-2  mvn deploy

在不搭建内部 PyPI 的前提下，这个问题一直没有找到一个完美的解决方案。实际操作中，是让cd common-libs; mvn install调用至python setup.py install --user，在本地安装 common-libs。

语言风格

程序员都是个性动物，写出的代码各种风格都有。在大型项目中，统一的代码风格非常有必要。Python 哲学里也有 preferably only one way to do it ⁶。流行的 Lint 工具有这么几种：

• Syntax errors and inconsistencies (using Pyflakes or Pylint)
• PEP8 violations
• PEP257 violations

这里边，轻量级的是PEP8和Pyflakes。建议任何时候都开。当你灵感满溢思如泉涌啪啪啪敲键盘时，它们在后台默默的保持最基本检查，绝不干扰思路，充分体现自由。重量级的Pylint和PEP257可以作为持续集成任务定时对整个代码库检查。当然，如果你是追求完美的处女座，全部打开也没有问题的，妈妈再也不用担心我的代码写的乱七八糟了。

实践中，我们把Pylint集成到maven compile，使提交入 git 的代码都是 lint 过的。

IDE

工欲善其事，必先利其器。好的 IDE 能帮助做这些事情：

• 生成遵循标准化目录结构的项目模板
• 提供语言风格的检查开关
• 管理 Python 运行环境
• 语法高亮
• 智能提示
• 自动完成

土豪就上公认神器 PyCharm 专业版。否则，Eclipse 装上 PyDev 也能凑合。极客就用 Sublime + Anaconda，我是用的很高兴的。

本篇到此结束。请看下篇 Python 的代码编写。