python 全栈开发，Day29(昨日作业讲解,模块搜索路径,编译python文件,包以及包的import和from,软件开发规范)
一、昨日作业讲解
先来回顾一下昨日的内容
1.os模块
和操作系统交互
工作目录 文件夹 文件 操作系统命令 路径相关的
2.模块
最本质的区别 import会创建一个专属于模块的名字，
所有导入模块中的都会在这个空间中
import
from import
as 起别名
* 和 __all__
作业讲解：
os.listdir() 返回一个列表，里面的每一个元素都是相对路径
值就是文件，或者文件夹
使用递归的方式实现
import os
def get_size(dir):
sum_size = 0 # 初始大小
for item in os.listdir(dir): # 返回一个列表，里面的每一个元素都是相对路径
path = os.path.join(dir,item) # 由于item是相对路径的文件或者文件夹，需要join拼出绝对路径
if os.path.isfile(path): # 判断绝对路径是否为文件
sum_size += os.path.getsize(path) # 计算文件大小
else:
sum_size += get_size(path) # 调用自身函数。加上文件夹的大小，固定为4096，空的也是那么大。
return sum_size
ret = get_size('E:\python_script\day26') # 传入一个目录
print(ret)
执行输出：
4950326
栈（先进先出）
使用栈的思想完成上面的代码：
import os
def get_size(path):
l = [path] # 文件夹列表
sum_size = 0 # 初始文件大小
while l: # 判断列表是否为空
path = l.pop() # 删除列表最后一个元素，并返回给path l = ['E:\python_script\day26']
for item in os.listdir(path): #遍历列表,path = 'E:\python_script\day26'
path2 = os.path.join(path, item) # 组合绝对路径 path2 = 'E:\python_script\day26\test'
if os.path.isfile(path2): # 判断绝对路径是否为文件
sum_size += os.path.getsize(path2) # 计算文件大小。sum = 文件的大小 + 0
else:
l.append(path2) # 为文件夹时,添加到列表中。再次循环。l = ['E:\python_script\day26\test']
return sum_size
print(get_size('E:\python_script\day26'))
执行输出：
4951192
和上面的结果有微小的差异，是因为，当前py文件，增加了几行代码。
查看文件夹属性
大小是一致的，有些windows系统，可能有微小的差异。
栈也可以解决深度问题，比如文件夹里面的所有文件统计
l就是一个栈
栈也可以完成递归的功能。
递归比较占用空间，每调用一次，产生一个新的空间
但是栈不会每次产生新的空间，非常节省空间
栈可以解决不确定深度问题
栈的精髓就是先进后出
第二题
思考：假如有两个模块a，b。 我可不可以在a模块中import b ，再在b模块中import a？
新建文件demo1.py，内容如下：
import my_module
print('demo1')
新建文件my_module.py，内容如下：
import demo1
print('my_module')
执行demo1.py，结果如下：
demo1
my_module
demo1
分析：
第一步执行demo1.py中的import my_module
第二步执行my_module.py中的import demo1
第三步执行demo1.py中的import my_module，发现mysql_modulel已经被导入了，那么不会再次导入！
第四步执行demo1.py中的print('demo1')，为什么呢？因为从上至下代码执行原则
第五步执行my_module.py中的print('my_module')，为什么呢？因为从上至下原则
引用有一个模块，是为了引用方法
修改demo1.py，增加一个函数
import my_module
def func():
print('ret')
my_module.func2() # 执行函数
修改my_module.py，增加一个函数
import demo1
def func2():
print('in func2')
demo1.func1()
执行demo1.py，输出报错：
AttributeError: module 'my_module' has no attribute 'func2'
为什么呢？
看我上面写的步骤分析，执行第4步时，由于my_module.py中的func2还没有加载到内容
执行第5步时，调用my_module中的func2函数，就会直接报错，提示找不到函数
结论：
代码不会发现循环引用问题
模块中的引用不能成环
看下面一张图
b引用a，c引用b。但是a不能引用c，否则就是一个环。反反复复，无法终止。
2个模块之间引用，那么就产生高层模块和底层模块
根据依赖倒置原则，高层模块不应该依赖底层模块
否则就违反了开发原则。
二、模块搜索路径
导入一个模块，就会从sys.path里面的路径中寻找
程序运行时，会将当前路径加入到搜索路径中
目前是demo1.py和my_module.py在同一个文件夹中
将my_module.py文件移动到上一层目录中
import sys print(sys.path)<br>import my_module # 执行报错
执行就会报错，因为sys.path提供的搜索路径中，找不到my_module.py文件
如果手动添加一个呢？
import sys
print(sys.path)
sys.path.append('E:\python_script\day26') # 添加搜索路径
import my_module
再次执行，就不会报错了。
能不能导入一个模块，不是靠Pycharm画红线决定的
而是sys.path决定的。
总结：
引入的模块必须满足两个条件
1.模块名必须满足变量名的规范
2.被导入的模块所在的位置必须在sys.path所在的搜索路径中
模块
py文件是一个模块
脚本
py文件也是一个模块
如果一个py文件被导入了 他就是一个模块
如果这个py文件被直接执行 这个被直接执行的文件就是一个脚本
模块
没有具体的调用过程
但是能对外提供功能
比如三次登录程序
创建文件login.py，内容如下：
def log_in():
user = input('>>>')
pwd = input('>>>')
print('三次登录')
创建文件test.py，内容如下：
import login login.log_in() # 执行登录
执行文件test.py，效果如下：
>>>111
>>>222
三次登录
现在有一个需求：
当login模块被当做脚本执行的时候，能够独立完成登陆功能
当login模块被当做模块导入的时候，需要等待调用才能完成功能
修改login.py
def log_in():
# user = input()
# pwd = input()
print('三次登陆')
print(__name__)
修改test.py
import login login.log_in() print(__name__)
执行test.py，输出：
login
三次登陆
__main__
说明由test.py调用login.py时，输出login，也就是模块名
如果login.py想直接执行log_in方法，但是不想被导入时，自动执行。可以做一个if判断
def log_in():
# user = input()
# pwd = input()
print('三次登陆')
if __name__ == '__main__':
log_in()
执行输出：三次登陆
修改test.py，只包含一行
import login
执行test.py，输出为空
if __name__ == '__main__': 这句话，永远不会变，它是为了区分脚本和模块
所有的print不应该出现在模块里面，而是出现在if下面的代码中
结论：
当一个模块被当做脚本执行的时候，__name__是一个字符串数据类型的'__main__'
当一个模块被当做模块导入的时候，__name__是一个字符串数据类型模块名
三、编译python文件
执行导入操作时,会自动创建目录__pycache__
查看里面的文件
那么这些文件是谁创建的呢？
python解释器创建的
当一个文件被当做模块导入的时候，
如果pyc文件不存，python解释器就会创建，存在不会再次被创建
pyc文件 编译文件
python --> 字节码 -->机器码
编译过程
从上到下 编译 成字节码 pyc
从上倒下 解释 执行代码
为什么要编译
1.一个文件如果作为模块 一定会经常被导入
2.每次被导入都要经历一个被编译的过程
3.包.编译耗费时间
4.所以模块在被第一次导入的时候被编译存在pyc文件里
5.之后的导入可以直接呐pyc文件中的字节码，就可以直接执行了
主要功能：
编译文件 在模块导入的一瞬间 能够提高代码的执行速度
不能提高程序在具体执行的时候的效率
程序第一次执行，可能会慢一点，因为有一个编译过程
补充:dir()函数
内建函数dir是用来查找模块中定义的名字，返回一个有序字符串列表
import my_module dir(my_module)
如果没有参数,dir()列举出当前定义的名字
dir()不会列举出内建函数或者变量的名字，它们都被定义到了标准模块builtin中，可以列举出它们，
import builtins dir(builtins)
四、包以及包的import和from
包是一种通过使用'.模块名' 来组织python模块名称空间的方式。
1. 无论是import形式还是from...import形式，凡是在导入语句中（而不是在使用时）遇到带点的，都要第一时间提高警觉：这是关于包才有的导入语法
2. 包是目录级的（文件夹级），文件夹是用py文件来组成（包的本质就是一个包含__init__.py文件的目录）
3. import导入文件时，产生名称空间中的名字来源于文件，import 包，产生的名称空间的名字同样来源于文件，即包下的__init__.py，导入包本质就是在导入该文件
强调：
1. 在python3中，即使包下没有__init__.py文件，import 包仍然不会报错，而在python2中，包下一定要有该文件，否则import 包报错
2. 创建包的目的不是为了运行，而是被导入使用，记住，包只是模块的一种形式而已，包即模块
使用Pycharm创建一个包，会自动创建__init__.py文件
所谓的包，就是一个包含__init__.py文件的文件夹
包A和包B下有同名模块也不会冲突，如A.a与B.a来自俩个命名空间
模块是对外提供功能的
如果我写的模块足够强大，能提供的功能足够多
多到一个文件写不
把对外提供的功能，根据提供的内容不同，分成几个文件
把这些文件放在一个文件夹下，就形成了包
比如django框架
是所有框架中，功能最全的
功能：
1.操作数据库的模块
2.和web页面交互的模块
3.登录认证的模块
4.安全的中间件 模块，比如web攻击
django将所有的模块集合成一个包
自动创建目录结构
import os
os.makedirs('glance/api')
os.makedirs('glance/cmd')
os.makedirs('glance/db')
l = []
l.append(open('glance/__init__.py','w'))
l.append(open('glance/api/__init__.py','w'))
l.append(open('glance/api/policy.py','w'))
l.append(open('glance/api/versions.py','w'))
l.append(open('glance/cmd/__init__.py','w'))
l.append(open('glance/cmd/manage.py','w'))
l.append(open('glance/db/models.py','w'))
map(lambda f:f.close() ,l)
执行代码，查看目录结构
文件内容如下：
#policy.py
def get():
print('from policy.py')
#versions.py
def create_resource(conf):
print('from version.py: ',conf)
#manage.py
def main():
print('from manage.py')
#models.py
def register_models(engine):
print('from models.py: ',engine)
手动将内容复制到对应的py文件中去
这里面的每一个文件夹，都是包
包里面的每一个py文件，都是模块
新建一个文件new.py
目录结构如下：
./ ├── glance │ ├── api │ │ ├── __init__.py │ │ ├── policy.py │ │ └── versions.py │ ├── cmd │ │ ├── __init__.py │ │ └── manage.py │ ├── db │ │ └── models.py │ └── __init__.py └── new.py
new.py想用glance目录下的api文件夹下的policy模块
修改new.py
from glance.api import policy policy.get()
执行输出：
from policy.py
注意事项
1.关于包相关的导入语句也分为import和from ... import ...两种，但是无论哪种，无论在什么位置，在导入时都必须遵循一个原则：凡是在导入时带点的，点的左边都必须是一个包，否则非法。可以带有一连串的点，如item.subitem.subsubitem,但都必须遵循这个原则。
2.对于导入后，在使用时就没有这种限制了，点的左边可以是包,模块，函数，类(它们都可以用点的方式调用自己的属性)。
3.对比import item 和from item import name的应用场景：
如果我们想直接使用name那必须使用后者。
也可以用这种写法：
import glance.api.policy glance.api.policy.get()
执行输出：
from policy.py
对于点没有约束，对比2种方式，使用from方式，就比较简单了。
from ... import ...
需要注意的是from后import导入的模块，必须是明确的一个不能带点，否则会有语法错误，如：from a import b.c是错误语法
这样就报错了
from glance import api.policy policy.get()
下面的方式，也是不对的
import glance glance.api.policy.get()
症结就是导入一个包，并没有把包里面的所有内容，导入进来
导入一个包，相当于执行了这个包下面的__init__.py文件
修改glance下面的__init__.py文件
import api
手动执行__init__.py文件，没有报错
修改new.py
import glance glance.api.policy.get()
执行new.py，提示报错
ImportError: No module named 'api'
为什么？
因为sys.path，路径中找不到api。__init__.py 执行时，在它的工作目录中可以找到api
但是new.py所在的工作目录，无法直接找到api目录，所以就报错了
绝对导入和相对导入
我们的最顶级包glance是写给别人用的，然后在glance包内部也会有彼此之间互相导入的需求，这时候就有绝对导入和相对导入两种方式：
绝对导入：以glance作为起始
相对导入：用.或者..的方式最为起始（只能在一个包中使用，不能用于不同目录内）
修改glance目录下的__init__.py文件
from glance import api
修改api目录下的__init__.py
from glance.api import policy
再次执行new.py，输出：
from policy.py
为什么呢？因为首先执行了glance目录下的__init__.py文件，再执行了api目录下的__init__.py
所以就能找到policy模块
所有导入，都是以glance为基础
这就是绝对路径导入
这个时候，新建一个文件new_pac
将glance目录剪切到new_pac
当前目录结构如下：
./ ├── new_pac │ └── glance │ ├── api │ │ ├── __init__.py │ │ ├── policy.py │ │ ├── __pycache__ │ │ │ ├── __init__.cpython-35.pyc │ │ │ └── policy.cpython-35.pyc │ │ └── versions.py │ ├── cmd │ │ ├── __init__.py │ │ └── manage.py │ ├── db │ │ └── models.py │ ├── __init__.py │ └── __pycache__ │ └── __init__.cpython-35.pyc └── new.py
如果new.py想调用new_pac目录下glance文件夹下面的内容呢？
修改new.py文件
from new_pac import glance glance.api.policy.get()
执行报错：
ImportError: No module named 'glance'
为什么？因为glance下的所有__init__.py路径不对，都得改
修改glance目录下的__init__.py
from new_pac.glance import api
修改api目录下的__init__.py
from new_pac.glance.api import policy
再次执行new.py，输出
from policy.py
但是这样太麻烦了，有缺点
一旦上级目录发生变化，那么所有的init_py，都得修改
总结：
绝对路径
被直接执行的文件与包的关系必须是固定的，
一旦发生改变，包内的所有关系都要重新指定
跨包引用的问题，无法解决
如果policy想要执行manage呢？
修改policy.py，内容如下：
from new_pac.glance.cmd import manage
def get():
print('from policy.py')
manage.main()
执行报错：
ImportError: No module named 'new_pac'
不能单独执行policy.py
它取决于sys.path
不改变new.py内容，执行new.py，输出：
from manage.py
from policy.py
结果正常。
特别需要注意的是：可以用import导入内置或者第三方模块（已经在sys.path中），但是要绝对避免使用import来导入自定义包的子模块(没有在sys.path中)，应该使用from... import ...的绝对或者相对导入,且包的相对导入只能用from的形式。
相对导入
用.或者..的方式最为起始（只能在一个包中使用，不能用于不同目录内）
好处就是，比方是你电脑开发的。换了另外一台电脑，也依然可以正常运行，不需要修改文件路径。
再次执行创建文件的脚本
import os
os.makedirs('glance/api')
os.makedirs('glance/cmd')
os.makedirs('glance/db')
l = []
l.append(open('glance/__init__.py','w'))
l.append(open('glance/api/__init__.py','w'))
l.append(open('glance/api/policy.py','w'))
l.append(open('glance/api/versions.py','w'))
l.append(open('glance/cmd/__init__.py','w'))
l.append(open('glance/cmd/manage.py','w'))
l.append(open('glance/db/models.py','w'))
map(lambda f:f.close() ,l)
再次补充文件内容
#policy.py
def get():
print('from policy.py')
#versions.py
def create_resource(conf):
print('from version.py: ',conf)
#manage.py
def main():
print('from manage.py')
#models.py
def register_models(engine):
print('from models.py: ',engine)
新建文件new2.py
目录结构如下：
./ ├── glance │ ├── api │ │ ├── __init__.py │ │ ├── policy.py │ │ └── versions.py │ ├── cmd │ │ ├── __init__.py │ │ └── manage.py │ ├── db │ │ └── models.py │ └── __init__.py └── new2.py
修改glance下的__init__.py，内容如下：
from . import api
点表示当前路径
api目录的__init__.py，内容如下：
from . import policy
修改new2.py，内容如下：
import glance glance.api.policy.get()
执行new2.py，输出：
from policy.py
新建目录new_pac2，将目录glance剪切到new_pac2下面
目录结构如下：
./
├── new2.py
└── new_pac2
└── glance
├── api
│ ├── __init__.py
│ ├── policy.py
│ └── versions.py
├── cmd
│ ├── __init__.py
│ └── manage.py
├── db
│ └── models.py
└── __init__.py
修改new2.py，内容如下：
from new_pac2 import glance glance.api.policy.get()
再次执行new2.py，输出：
from policy.py
居然没有报错，666啊!
修改policy.py，导入versions模块
from . import versions
def get():
print('from policy.py')
versions.create_resource('userinfo')
执行new2.py，输出：
from version.py: userinfo
from policy.py
手动执行policy.py，输出：
ImportError: attempted relative import with no known parent package
它不能当成脚本执行
结论：
在一个py文件中使用了相对路径引入一个模块
那么这个文件就不能被当成脚本运行了
修改policy.py，导入manage模块
from . import versions
from .. cmd import manage
def get():
print('from policy.py')
versions.create_resource('userinfo')
manage.main()
点点表示上一级目录
执行new2.py，输出：
from version.py: userinfo from manage.py from policy.py
new2.py 只能关联到glance包
from glance.api import *
在讲模块时，我们已经讨论过了从一个模块内导入所有*，此处我们研究从一个包导入所有*。
此处是想从包api中导入所有，实际上该语句只会导入包api下__init__.py文件中定义的名字，我们可以在这个文件中定义__all___:
修改policy.py
from . import versions
from ..cmd import manage
__all__ = ['get']
def get():
print('from policy.py')
versions.create_resource('userinfo')
manage.main()
修改api.py，内容如下：
from . import policy __all__ = ['policy']
修改new2.py
from new_pac2.glance.api import *
执行输出：
from version.py: userinfo
from manage.py
总结：
包就是py模块的集合
自带__init__.py文件
py2 包中必须有一个__init__.py文件
py3 不存在也可以
能不能导入一个包：要看sys.path中的路径下有没有这个包
从包中导入模块： 把包与包之间的关系写清楚，精确到模块，就一定能导入
直接导入一个包，并不会导入包下的模块，而是执行这个包下的__init__.py文件
如果对导入还有更高的要求
可以对包中的__init__.py文件做定义
绝对路径导入的方式
相对路径导入的方式 使用相对路径导入的模块不能作为脚本执行
sys.path是所有模块的核心
是导入的关键
记住下面的：
#导入具体的文件 #1.使用from from glance.api import policy policy.get() # #1.使用import加别名 import glance.api.policy as policy policy.get()
保你2年平安...
五、软件开发规范
比如校园管理系统，目录结构如下：
开始程序为start.py
为什么要设计好目录结构?
"设计项目目录结构"，就和"代码编码风格"一样，属于个人风格问题。
设计一个层次清晰的目录结构，就是为了达到以下两点:
1.可读性高: 不熟悉这个项目的代码的人，一眼就能看懂目录结构，知道程序启动脚本是哪个，测试目录在哪儿，配置文件在哪儿等等。从而非常快速的了解这个项目。
2.可维护性高: 定义好组织规则后，维护者就能很明确地知道，新增的哪个文件和代码应该放在什么目录之下。这个好处是，随着时间的推移，代码/配置的规模增加，项目结构不会混乱，仍然能够组织良好。
所以，我认为，保持一个层次清晰的目录结构是有必要的。更何况组织一个良好的工程目录，其实是一件很简单的事儿。
关于README的内容
这个我觉得是每个项目都应该有的一个文件，目的是能简要描述该项目的信息，让读者快速了解这个项目。
它需要说明以下几个事项:
1.软件定位，软件的基本功能。
2.运行代码的方法: 安装环境、启动命令等。
3.简要的使用说明。
4.代码目录结构说明，更详细点可以说明软件的基本原理。
5.常见问题说明。
我觉得有以上几点是比较好的一个README。在软件开发初期，由于开发过程中以上内容可能不明确或者发生变化，并不是一定要在一开始就将所有信息都补全。但是在项目完结的时候，是需要撰写这样的一个文档的。
可以参考Redis源码中Readme的写法，这里面简洁但是清晰的描述了Redis功能和源码结构。
https://github.com/antirez/redis#what-is-redis
