2013年一月月 发布的文章

关于Python Package下的Module import方式

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 RossumPEP 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版本下测试通过。

梅西与四座金球

今天凌晨西班牙国王杯四分之一决赛首轮,巴萨在诺坎普迎来了马拉加队的挑战。尽管巴萨在最后时刻遗憾地丟球被马拉加扳平比分,但这场比赛的另外一个看点却是金球之王梅西公开展示他的四座金球。作为梅西球迷,巴萨球迷,挑了一张图片,以示纪念^_^。

下面是之前梅西拍的金球写真,我觉得也不错。

buildc 0.2.2版本发布

随着buildc在项目中的深入使用,开发和测试人员都提出了不少良好意见,让我们有些应接不暇了,这次的版本更新也是为了满足这些意见和建议。 由于忙于应对这些眼前的需求,原本0.3.0的改进计划也被推迟了一些。

buildc 0.2.2版本包含了两个主要修正。

* 增加了–ignore-error命令行选项

自从buildc cache相关命令严格区分–cmode=32-bit还是64-bit后,用户在使用过程中出现了一些新情况。比如某开发人员A负责两个子系统 subsys1和subsys2的开发,这两个子系统分别用到了lib1和lib2。subsys1是一个64bit系统,依赖lib1;而 subsys2是一个32bit系统。依赖lib2。这样开发人员A在自己的开发环境下要管理和缓存lib1和lib2。管理lib1时,用到的 是buildc cache update –cmode=64-bit命令,而管理lib2时,用到的是buildc cache update –cmode=32-bit命令。这时如果内部的二进制库服务器上没有lib1的32bit版本或者没有lib2的64bit版本,buildc cache相关命令就会执行失败。为了临时解决这个问题,我们增加了–ignore-error命令行选项,这样即便lib1无32bit版本 或者lib2无64bit版本,buildc cache相关命令执行不会失败,开发人员A开发环境下的subsys1和subsys2的构建也会顺利完成。

关于这个问题,后续期待在buildc 0.3.0版本或后续版本得到更好的解决。

* 增加buildc pack source –component=[src|deps|all]命令

通常情况下,我们是不需要在生产环境下做任何编译操作的。但有些特殊情况下,我们不得不将源码拿到生产环境下进行编译。之前使用buildc进行 源码构建的工程拿到生产环境下进行编译极为不便,因为生产环境下没有buildc环境,也没有依赖库的cache,因此我们的运维人员提出这样的 需求:提供一份可在生产环境下进行编译的source包。为了满足这一需求,我们针对setup工程进行了完善,对buildc的pack命令做 了扩充,使得buildc pack支持source打包。

buildc pack source支持三个component参数:src、deps和all。src意为源码包,包中只包含工程源码;deps是打依赖包,及包中包含的都是 工程依赖的对应平台的第三方库的二进制版本;all则是src和deps的合体,是一个全量的,在目标环境可直接编译的包。

buildc pack source输出的目标包内结构大致如下:

target-package/
    – deps/
        – lib1/
            – 1.1.0/
                – x86_64_linux/
    – proj_name
        – configure
        – Make.rules
        – Makefile
        – ….

前面说过,这个包在目标环境是直接可编译的,你只需执行:
$>./configure
$> make

在制作目标包时,buildc pack source命令就已经将Make.rules中的各种库的依赖信息按照目标包的结构做了调整。执行configure是为了根据目标环境对 Make.rules做最后的调整。

另外源码包仅携带对应目标平台的第三方库的版本,不会将所有平台的版本都带上。当然这样有利有弊。优点在于源码包的size不会很大;缺点在于, 如果生产环境有许多种平台的话,我们需要为每个平台准备一份源码包。

BTW,现在的buildc基本上由我们组的小兄弟wtz1989227一个人维护,包括buildc的manual更新,这次的更新也都是他一 个人的工作成果。小声的说一句:wtz1989227接触Python也为时不多,因此代码方面还有较大的改进提高余地。 




这里是Tony Bai的个人Blog,欢迎访问、订阅和留言!订阅Feed请点击上面图片

如果您觉得这里的文章对您有帮助,请扫描上方二维码进行捐赠,加油后的Tony Bai将会为您呈现更多精彩的文章,谢谢!

如果您希望通过微信捐赠,请用微信客户端扫描下方赞赏码:


如果您希望通过比特币或以太币捐赠,可以扫描下方二维码:

比特币:


以太币:


如果您喜欢通过微信App浏览本站内容,可以扫描下方二维码,订阅本站官方微信订阅号“iamtonybai”;点击二维码,可直达本人官方微博主页^_^:



本站Powered by Digital Ocean VPS。

选择Digital Ocean VPS主机,即可获得10美元现金充值,可免费使用两个月哟!

著名主机提供商Linode 10$优惠码:linode10,在这里注册即可免费获得。

阿里云推荐码:1WFZ0V立享9折!

View Tony Bai's profile on LinkedIn


文章

评论

  • 正在加载...

分类

标签

归档











更多