Python编程指南：从入门到精通

需积分: 10 127 浏览量更新于2024-07-21 收藏 371KB PDF 举报

“Python Guide” 这份文档是Python编程的综合指南，由Kenneth Reitz于2014年10月15日发布。它涵盖了从安装Python到编写、测试、打包和部署高质量代码的全过程，同时也涉及了各种应用场景和开发环境的设置。 1. 开始学习Python - 选择解释器：在开始Python编程之前，你需要选择一个适合的Python解释器，这可能包括Python 2或Python 3，根据项目需求和个人偏好来决定。 - 在MacOSX上安装Python：提供了在苹果操作系统上安装Python的步骤，通常推荐使用Homebrew或官方Python网站的安装程序。 - 在Windows上安装Python：指导用户如何在Windows系统中安装Python，通常可以通过下载并运行Python的安装程序来完成。 - 在Linux上安装Python：Linux用户通常可以通过包管理器（如apt-get、yum或dnf）轻松安装Python。 2. 编写优秀的代码 - 项目结构：讨论了如何合理地组织代码，使项目结构清晰易懂，便于维护。 - 编码风格：强调了遵循一定的代码风格，如PEP 8，以提高代码可读性和一致性。 - 阅读优质代码：鼓励程序员阅读和理解他人的高质量代码，以提升自己的编程技巧。 - 文档编写：强调了编写良好文档的重要性，帮助他人理解你的代码。 - 测试代码：介绍了单元测试、集成测试等方法，确保代码的健壮性和可靠性。 - 常见陷阱：列举了一些编程过程中常见的错误和陷阱，提醒开发者避免这些问题。 - 选择许可证：讨论了为项目选择合适的开源许可证，如MIT、Apache 2.0等。 3. 场景应用指南 - 网络应用：涵盖了网络编程的基础，如TCP/IP通信和HTTP协议。 - Web应用：介绍如何使用Python构建Web应用程序，包括框架如Flask和Django。 - HTML抓取：讲解了网页数据提取技术，如使用BeautifulSoup库进行网页抓取。 - 命令行应用：阐述了创建交互式命令行工具的方法。 - 图形用户界面（GUI）应用：讨论了使用Tkinter、PyQt等库创建桌面应用程序。 - 数据库操作：介绍了如何与MySQL、SQLite等数据库进行交互。 - 网络编程：涵盖了套接字编程和网络服务。 - 系统管理：展示了Python在自动化系统管理和脚本中的应用。 - 持续集成：解释了如何设置持续集成（CI）以自动测试和部署代码。 - 性能优化：讨论了提高Python代码执行速度的策略。 - 科学计算：介绍了NumPy、SciPy等库在科学计算中的应用。 - 图像处理：讲述了如何利用PIL、OpenCV等库进行图像处理。 - XML解析：讲解了处理XML数据的Python库，如ElementTree。 - 密码学：介绍了使用Python进行加密和安全通信的库，如PyCrypto。 4. 发布优质代码 - 打包代码：指导如何将项目打包成可分发的Python包，以便其他用户安装和使用。 - 冻结代码：介绍了将Python应用打包成独立的可执行文件，以便在没有Python环境的机器上运行。 5. 开发环境 - 开发环境的配置：讨论了如何配置个人开发环境，包括编辑器、IDE的选择和设置。 - 虚拟环境：推荐使用virtualenv或venv来创建隔离的Python环境，防止版本冲突。 6. 附加注释 - 社区介绍：提到了Python社区的资源、活动和参与方式，鼓励用户参与和贡献。这份指南对于Python初学者和有经验的开发者都是宝贵的资源，旨在帮助他们提升技能，更好地理解和应用Python。

CHAPTER 2

Writing Great Code

This part of the guide focuses on best practices for writing Python code.

2.1 Structuring Your Project

By “structure” we mean the decisions you make concerning how your project best meets its objective. We need to

consider how to best leverage Python’s features to create clean, effective code. In practical terms, “structure” means

making clean code whose logic and dependencies are clear as well as how the ﬁles and folders are organized in the

ﬁlesystem.

Which functions should go into which modules? How does data ﬂow through the project? What features and functions

can be grouped together and isolated? By answering questions like these you can begin to plan, in a broad sense, what

your ﬁnished product will look like.

In this section we take a closer look at Python’s module and import systems as they are the central elements to enforcing

structure in your project. We then discuss various perspectives on how to build code which can be extended and tested

reliably.

2.1.1 Structure is Key

Thanks to the way imports and modules are handled in Python, it is relatively easy to structure a Python project. Easy,

here, means that you do not have many constraints and that the module importing model is easy to grasp. Therefore,

you are left with the pure architectural task of crafting the different parts of your project and their interactions.

Easy structuring of a project means it is also easy to do it poorly. Some signs of a poorly structured project include:

• Multiple and messy circular dependencies: if your classes Table and Chair in furn.py need to import Car-

penter from workers.py to answer a question such as table.isdoneby(), and if conversely the class

Carpenter needs to import Table and Chair, to answer the question carpenter.whatdo(), then you have a

circular dependency. In this case you will have to resort to fragile hacks such as using import statements inside

methods or functions.

• Hidden coupling: each and every change in Table’s implementation breaks 20 tests in unrelated test cases

because it breaks Carpenter’s code, which requires very careful surgery to adapt the change. This means you

have too many assumptions about Table in Carpenter’s code or the reverse.

• Heavy usage of global state or context: instead of explicitly passing (height, width, type, wood)

to each other, Table and Carpenter rely on global variables that can be modiﬁed and are modiﬁed on the ﬂy

by different agents. You need to scrutinize all access to these global variables to understand why a rectangular

table became a square, and discover that remote template code is also modifying this context, messing with table

dimensions.

Python Guide Documentation, Release 0.0.1

• Spaghetti code: multiple pages of nested if clauses and for loops with a lot of copy-pasted procedural code

and no proper segmentation are known as spaghetti code. Python’s meaningful indentation (one of its most

controversial features) make it very hard to maintain this kind of code. So the good news is that you might not

see too much of it.

• Ravioli code is more likely in Python: it consists of hundreds of similar little pieces of logic, often classes or

objects, without proper structure. If you never can remember if you have to use FurnitureTable, AssetTable or

Table, or even TableNew for your task at hand, you might be swimming in ravioli code.

2.1.2 Modules

Python modules are one of the main abstraction layers available and probably the most natural one. Abstraction layers

allow separating code into parts holding related data and functionality.

For example, a layer of a project can handle interfacing with user actions, while another would handle low-level

manipulation of data. The most natural way to separate these two layers is to regroup all interfacing functionality in

one ﬁle, and all low-level operations in another ﬁle. In this case, the interface ﬁle needs to import the low-level ﬁle.

This is done with the import and from ... import statements.

As soon as you use import statements you use modules. These can be either built-in modules such as os and sys,

third-party modules you have installed in your environment, or your project’s internal modules.

To keep in line with the style guide, keep module names short, lowercase, and be sure to avoid using special symbols

like the dot (.) or question mark (?). So a ﬁle name like my.spam.py is one you should avoid! Naming this way will

interfere with the way Python looks for modules.

In the case of my.spam.py Python expects to ﬁnd a spam.py ﬁle in a folder named my which is not the case. There is

an example of how the dot notation should be used in the Python docs.

If you’d like you could name your module my_spam.py, but even our friend the underscore should not be seen often

in module names.

Aside from some naming restrictions, nothing special is required for a Python ﬁle to be a module, but you need to

understand the import mechanism in order to use this concept properly and avoid some issues.

Concretely, the import modu statement will look for the proper ﬁle, which is modu.py in the same directory as

the caller if it exists. If it is not found, the Python interpreter will search for modu.py in the “path” recursively and

raise an ImportError exception if it is not found.

Once modu.py is found, the Python interpreter will execute the module in an isolated scope. Any top-level statement

in modu.py will be executed, including other imports if any. Function and class deﬁnitions are stored in the module’s

dictionary.

Then, the module’s variables, functions, and classes will be available to the caller through the module’s namespace, a

central concept in programming that is particularly helpful and powerful in Python.

In many languages, an include file directive is used by the preprocessor to take all code found in the ﬁle and

‘copy’ it into the caller’s code. It is different in Python: the included code is isolated in a module namespace, which

means that you generally don’t have to worry that the included code could have unwanted effects, e.g. override an

existing function with the same name.

It is possible to simulate the more standard behavior by using a special syntax of the import statement: from modu

import

. This is generally considered bad practice. Using import

makes code harder to read and makes

dependencies less compartmentalized.

Using from modu import func is a way to pinpoint the function you want to import and put it in the global

namespace. While much less harmful than import

because it shows explicitly what is imported in the global

namespace, its only advantage over a simpler import modu is that it will save a little typing.

Very bad

12 Chapter 2. Writing Great Code

Python Guide Documentation, Release 0.0.1

[...]

from modu import

[...]

x = sqrt(4) # Is sqrt part of modu? A builtin? Defined above?

Better

from modu import sqrt

[...]

x = sqrt(4) # sqrt may be part of modu, if not redefined in between

Best

import modu

[...]

x = modu.sqrt(4) # sqrt is visibly part of modu’s namespace

As mentioned in the Code Style section, readability is one of the main features of Python. Readability means to avoid

useless boilerplate text and clutter, therefore some efforts are spent trying to achieve a certain level of brevity. But

terseness and obscurity are the limits where brevity should stop. Being able to tell immediately where a class or

function comes from, as in the modu.func idiom, greatly improves code readability and understandability in all but

the simplest single ﬁle projects.

2.1.3 Packages

Python provides a very straightforward packaging system, which is simply an extension of the module mechanism to

a directory.

Any directory with an __init__.py ﬁle is considered a Python package. The different modules in the package are

imported in a similar manner as plain modules, but with a special behavior for the __init__.py ﬁle, which is used

to gather all package-wide deﬁnitions.

A ﬁle modu.py in the directory pack/ is imported with the statement import pack.modu. This statement will

look for an __init__.py ﬁle in pack, execute all of its top-level statements. Then it will look for a ﬁle named

pack/modu.py and execute all of its top-level statements. After these operations, any variable, function, or class

deﬁned in modu.py is available in the pack.modu namespace.

A commonly seen issue is to add too much code to __init__.py ﬁles. When the project complexity grows, there

may be sub-packages and sub-sub-packages in a deep directory structure. In this case, importing a single item from a

sub-sub-package will require executing all __init__.py ﬁles met while traversing the tree.

Leaving an __init__.py ﬁle empty is considered normal and even a good practice, if the package’s modules and

sub-packages do not need to share any code.

Lastly, a convenient syntax is available for importing deeply nested packages: import very.deep.module as

mod. This allows you to use mod in place of the verbose repetition of very.deep.module.

2.1.4 Object-oriented programming

Python is sometimes described as an object-oriented programming language. This can be somewhat misleading and

needs to be clariﬁed.

In Python, everything is an object, and can be handled as such. This is what is meant when we say, for example, that

functions are ﬁrst-class objects. Functions, classes, strings, and even types are objects in Python: like any objects, they

have a type, they can be passed as function arguments, they may have methods and properties. In this understanding,

Python is an object-oriented language.

2.1. Structuring Your Project 13

Python Guide Documentation, Release 0.0.1

However, unlike Java, Python does not impose object-oriented programming as the main programming paradigm. It

is perfectly viable for a Python project to not be object-oriented, i.e. to use no or very few class deﬁnitions, class

inheritance, or any other mechanisms that are speciﬁc to object-oriented programming.

Moreover, as seen in the modules section, the way Python handles modules and namespaces gives the developer a

natural way to ensure the encapsulation and separation of abstraction layers, both being the most common reasons to

use object-orientation. Therefore, Python programmers have more latitude to not use object-orientation, when it is not

required by the business model.

There are some reasons to avoid unnecessary object-orientation. Deﬁning custom classes is useful when we want to

glue together some state and some functionality. The problem, as pointed out by the discussions about functional

programming, comes from the “state” part of the equation.

In some architectures, typically web applications, multiple instances of Python processes are spawned to respond

to external requests that can happen at the same time. In this case, holding some state into instantiated objects,

which means keeping some static information about the world, is prone to concurrency problems or race-conditions.

Sometimes, between the initialization of the state of an object (usually done with the __init__() method) and the

actual use of the object state through one of its methods, the world may have changed, and the retained state may be

outdated. For example, a request may load an item in memory and mark it as read by a user. If another request requires

the deletion of this item at the same time, it may happen that the deletion actually occurs after the ﬁrst process loaded

the item, and then we have to mark as read a deleted object.

This and other issues led to the idea that using stateless functions is a better programming paradigm.

Another way to say the same thing is to suggest using functions and procedures with as few implicit contexts and side-

effects as possible. A function’s implicit context is made up of any of the global variables or items in the persistence

layer that are accessed from within the function. Side-effects are the changes that a function makes to its implicit

context. If a function saves or deletes data in a global variable or in the persistence layer, it is said to have a side-effect.

Carefully isolating functions with context and side-effects from functions with logic (called pure functions) allow the

following beneﬁts:

• Pure functions are deterministic: given a ﬁxed input, the output will always be the same.

• Pure functions are much easier to change or replace if they need to be refactored or optimized.

• Pure functions are easier to test with unit-tests: There is less need for complex context setup and data cleaning

afterwards.

• Pure functions are easier to manipulate, decorate, and pass-around.

In summary, pure functions, without any context or side-effects, are more efﬁcient building blocks than classes and

objects for some architectures.

Obviously, object-orientation is useful and even necessary in many cases, for example when developing graphical

desktop applications or games, where the things that are manipulated (windows, buttons, avatars, vehicles) have a

relatively long life of their own in the computer’s memory.

2.1.5 Decorators

The Python language provides a simple yet powerful syntax called ‘decorators’. A decorator is a function or a class that

wraps (or decorates) a function or a method. The ‘decorated’ function or method will replace the original ‘undecorated’

function or method. Because functions are ﬁrst-class objects in Python, this can be done ‘manually’, but using the

@decorator syntax is clearer and thus preferred.

def foo():

# do something

def decorator(func):

# manipulate func

14 Chapter 2. Writing Great Code

Python Guide Documentation, Release 0.0.1

return func

foo = decorator(foo) # Manually decorate

@decorator

def bar():

# Do something

# bar() is decorated

This mechanism is useful for separating concerns and avoiding external un-related logic ‘polluting’ the core logic

of the function or method. A good example of a piece of functionality that is better handled with decoration is

memoization or caching: you want to store the results of an expensive function in a table and use them directly instead

of recomputing them when they have already been computed. This is clearly not part of the function logic.

2.1.6 Dynamic typing

Python is said to be dynamically typed, which means that variables do not have a ﬁxed type. In fact, in Python,

variables are very different from what they are in many other languages, speciﬁcally statically-typed languages. Vari-

ables are not a segment of the computer’s memory where some value is written, they are ‘tags’ or ‘names’ pointing

to objects. It is therefore possible for the variable ‘a’ to be set to the value 1, then to the value ‘a string’, then to a

function.

The dynamic typing of Python is often considered to be a weakness, and indeed it can lead to complexities and hard-

to-debug code. Something named ‘a’ can be set to many different things, and the developer or the maintainer needs to

track this name in the code to make sure it has not been set to a completely unrelated object.

Some guidelines help to avoid this issue:

• Avoid using the same variable name for different things.

Bad

a = 1

a = ’a string’

def a():

pass # Do something

Good

count = 1

msg = ’a string’

def func():

pass # Do something

Using short functions or methods helps reduce the risk of using the same name for two unrelated things.

It is better to use different names even for things that are related, when they have a different type:

Bad

items = ’a b c d’ # This is a string...

items = items.split(’ ’) # ...becoming a list

items = set(items) # ...and then a set

There is no efﬁciency gain when reusing names: the assignments will have to create new objects anyway. However,

when the complexity grows and each assignment is separated by other lines of code, including ‘if’ branches and loops,

it becomes harder to ascertain what a given variable’s type is.

Some coding practices, like functional programming, recommend never reassigning a variable. In Java this is done

with the ﬁnal keyword. Python does not have a ﬁnal keyword and it would be against its philosophy anyway. However,

2.1. Structuring Your Project 15

剩余92页未读，继续阅读

sinat_30036203

粉丝: 0
资源: 1

Python编程指南：从入门到精通

Python Guide

python指南

python-guide

Python Guide Documentation

python guide source3

Fullstack python Guide to development

The Full Stack Python Guide to Deployments

Python Guide Document--写出好的代码

Python Guide Documentation Release 0.0.1-Kenneth Reitz（中文版html+英文文字版）

python-guide python引言

最新资源