2012年有一个目标我没有达成，那就是深入学习和使用Python语言。这个目标被其他学习任务和工作无情的抢占了，当然最主要的原因还是我重视不够^_^。

近期恰逢有一些Python工程的开发工作要做，就顺便略微深入地学习了一下Python：看了几本Python的英文大部头，比如《Learning Python 4th Edition》、《Python Essential Reference 4th Edition》、《Programming Python 4th Edition》、《Expert Python Programming》以及《The Python standard library by example》，看得我有些要吐了^_^。虽然之前用Python开发过buildc，但自我感觉依旧还是一个Python的绝对beginner，这 次通过这几本书的学习算是对Python有了个较为系统的了解了。

言归正传，今天要探讨的是一个有关Python Package下的Module import的问题，这是我在进行一个Python工程源码组织设计时遇到的。一般来说，我们的工程代码组织形式如下：

py-proj/
    main.py
    pkg1/
        __init__.py
        mod1.py
    pkg2/
        __init__.py
        mod2.py
    test/
        __init__.py
        testmod1.py
        testmod2.py

工程的dev需求如下：

* 执行main.py(其中import了各个pkg的module)
* 能够单独执行pkg下的某个module
* 兄弟pkg间可以相互import module
* 能够单独执行test下的某个module的test用例
* 能够一次执行test下的所有module的test用例

基于工程的这些dev需求，我们来看一下module import方式的选择。

Python自2.5版本之后支持两种package import方式：absolute import和relative import。不过Guido van Rossum在PEP 8中明确建议采用absolute import，理由是：more portable和more readable。经过试验，我个人觉得Guido van Rossum的建议是十分中肯的。relative import在不同版本间的支持语义有差别，且在理解方面显得有些复杂。《Learning Python 4th Edition》中花了将近一个小节来讲Package relative import，感觉复杂难懂。虽然relative import能解决一些问题，但感觉投入产出比不高。我们来看看package absolute import能否满足我们的所有工程dev需求。

* 执行main.py

无论当前工作目录（current working directory)是哪个目录，一旦执行main.py，Python就会自动将main.py所在的目录添加到sys.path中去，作为一个 module search path的entry。这样只要工程下的文件都采用了absolute import，Python就可以正确找到并import正确的module。

* 单独执行某pkg下的某个module

我们在dev时有这样的需求：单独执行某个正在编写的module的代码以获得一些执行结果的反馈。不过，以上面例子中的代码结构为例，如果我们进入到 pkg1目录下执行python mod1.py，一旦mod1.py引用了pkg2.mod2，你就会收到如下错误（前提是你使用了absolute import）：

$ python mod1.py

Traceback (most recent call last):
  File "mod1.py", line 2, in <module>
    import pkg2.mod2
ImportError: No module named pkg2.mod2

因为Python只是将pkg1这个路径加入到module search path中了，这个路径下显然没有pkg2/mod2.py。不过我们可以通过在工程top-level路径下执行"python -m pkg1.mod1"来单独执行mod1的代码，这样absolute import依然生效，不会导致import error。

* 兄弟pkg间可以相互import module

这个与上面的执行方法类似，只要在top-level下通过python -m执行，那么无论pkg层次多深，无论有多少兄弟package，Python总是可以找到正确的module并导入。

* 单独执行test下的某个module的test用例

这有些类似于引用兄弟package的情况。我们通过在顶层路径下执行python -m test.testmod1即可达到此目的。

* 一次执行test下的所有module的test用例

较新的Python版本已经可以自动发现测试用例并执行。我们通过在top-level目录执行python -m unittest discover test即可执行test目录下所有符合unittest包约定要求的单元测试用例文件。在执行这个命令时，Python会将top-level路径以及 test路径都加入到module search path中。

终上，Absolute import可以满足所有需求。虽然有时候absolute import从代码上会看起来有些冗长(通过from … import …能有所缓解)，但在语义理解的简单性和可读性上的优势让我更加倾向于这种方式。另外通常情况下我们是无需重新设置PYTHONPATH，也用不 到.pth文件，更不需在代码里修改sys.path来改变Python的module search path的。

注：以上测试均在Ubuntu 12.04 LTS Python 2.7.3版本下测试通过。

趁着世界末日尚未到来，赶紧将2012年总结一番，即便是末日也不能留遗憾不是^_^。

2012年总体过得还算充实：

*《七周七语言》终于出版了；
* 写了近80篇Blog，虽离目标预期还有差距，但也给我带来了不小的精神愉悦；
* 为《程序员》杂志写了两篇文章，虽然都是短文；
* 读了30多本书，还有10多本尚未读完，不过年初制定的“扫存书”目标没能达成，因为依然不断地有大量的新书加入^_^；
* 学习了一门编程语言Go（而不是年初确定的Clojure等）；
* 将自己的一些关于工作方法、团队建设和管理的认知和实践总结了出来，算是一个阶段性的小结，内容包括绩效目标制定、绩效面谈、高效会议、写好Mail、个人时间管理、知识管理新认知、团队经营等诸多方面。也许后续还有补充。

2012年在工作方面的表现略显平淡。恰应了那句古语：有心栽花花不活。年初和团队成员共同确定了今年的年度主题词为“收获”，但一年下来的结果 却是差强人意：我最重视的一个关键项目没能如期发布，可谓是今年之最大憾事。我的责任自然不能脱掉，主因在于我年初过于乐观的估计。至于在其他方 面即便有较大进展，也无法弥补这一遗憾给我带来的不快。

2012年将buildc实际应用到了产品构建中，同时发现了诸多问题，也收到了许多同事的反馈。buildc也因此在持续演进，从0.1.4版本到 目前的0.2.1版本。近期正在酝酿0.3.x版本，这次改动较大，调整了很多当初的设计思路，与0.2.x版本并不兼容了。

2012年在家庭方面自我感觉收获还是颇多的。从数字上看，年初确定的年度家庭目标80%都实现了，这些目标有对父母的、有对孩子的，也有对LP 的，这让我颇为欣慰啊。最让我欣喜的是看到了女儿果果的成长，尤其是其语言能力的提升，让我们从此不必再担心了。现在面对果果这样一个已经可以与 我进行语言交流的小家伙儿，心中总是有一种莫名的感动，感谢上天赐予我这个可爱的小家伙儿 ^_^。将心比心，现在真心感觉到父母对待子女可真是没有半点私心，都是全心全力的为儿女服务，所以每个人都更应该善待父母。今年下半年，母亲得了眼 病，做了一个小手术，我也请假回家照顾。平时和父母不在一个城市生活，方方面面无法顾及，甚感惭愧，这次回家让我心灵有了些许慰藉，也让我第一次有了尽孝道的感觉。以后我每年都会设定家庭目标，但今后的家庭目标实现难度都很大，尽力而为吧^_^。

读书已然是生活中不可缺少的一部分了，但2012年似乎有些懒惰了。虽然读的书目也不少，但总感觉缺少些效率。

过去的都过去了，2012虽有小成，但觉得进步有限。身旁的人与物太过熟悉稳定，人就会变得像温水中的那只青蛙。

2013，期待能有些变化。