Python的特征与生态环境
-
特征:轻便/一致/开发者生产力高/大量的库/软件质量/软件集成/满足与享受
-
缺点:执行速度
-
当运行Python程序时,会生成
.pyc
文件 - Python编译后的字节码,然后被Python解释器运行 -
使用Python的公司:Goolge, YouTube, Dropbox, Red Hat, IBM, HP, Yahoo ...
-
使用Python的游戏:Battlefield 2,Civilization IV, QuArK ...
-
Python用途:系统编程,Web开发,GUI应用,游戏和机器人,数据科学,数据库应用 ...
Python环境搭建
注意: 简便起见,开发环境统一用Docker搭建, Docker for mac/win/linux, 安装详情请移步Docker贴士文集
-
在某些方面Python 2 和 Python 3不兼容
-
安装Python:
docker run -ti --rm python:alpine python
运行Python程序
-
四种方式: Python脚本/Python交互式shell/Python服务/Python GUI应用
-
交互式shell:
➜ ~ docker run --rm -ti python:alpine python
Python 3.7.0 (default, Jul 4 2018, 02:26:27)
[GCC 6.4.0] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> 1 + 1
2
>>> 100 / 23
4.3478260869565215
>>> 2 ** 2048
32317006071311007300714876688669951960444102669715484032130345427524655138867890893197201411522913463688717960921898019494119559150490921095088152386448283120630877367300996091750197750389652106796057638384067568276792218642619756161838094338476170470581645852036305042887575891541065808607552399123930385521914333389668342420684974786564569494856176035326322058077805659331026192708460314150258592864177116725943603718461857357598351152301645904403697613233287231227125684710820209725157101726931323469678542580656697935045997268352998638215525166389437335543602135433229604645318478604952148193555853611059596230656
>>>
- GUI:
PyQt / wxPython / PyGTK
Python代码组织与执行模型
代码组织
-
.py
文件 作为 Python模块 - 包含
__init__.py
(Python 3.3 不再是必需的)文件夹 作为package
执行模型:
-
name vs namespace
from library.second_floor.section_x.row_three import book
namespace:library
second_floor
section_x
row_three
name:book
-
Scopes (LEGB)
查找name的顺序: local -> enclosing -> global -> built-in -
对象与类
类用来创建对象, 对象是类的实例
编写好的代码
PEP 8 -- Style Guide for Python Code
➜ ~ docker run --rm -ti python:alpine python
Python 3.7.0 (default, Jul 4 2018, 02:26:27)
[GCC 6.4.0] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> import this
The Zen of Python, by Tim Peters
Beautiful is better than ugly.
Explicit is better than implicit.
Simple is better than complex.
Complex is better than complicated.
Flat is better than nested.
Sparse is better than dense.
Readability counts.
Special cases aren't special enough to break the rules.
Although practicality beats purity.
Errors should never pass silently.
Unless explicitly silenced.
In the face of ambiguity, refuse the temptation to guess.
There should be one-- and preferably only one --obvious way to do it.
Although that way may not be obvious at first unless you're Dutch.
Now is better than never.
Although never is often better than *right* now.
If the implementation is hard to explain, it's a bad idea.
If the implementation is easy to explain, it may be a good idea.
Namespaces are one honking great idea -- let's do more of those!
>>>
网友评论