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

需积分: 7 20 浏览量更新于2024-07-23 收藏 362KB PDF 举报

"PythonGuide" 是一份详细的Python学习指导文档，由Kenneth Reitz于2014年8月9日发布，旨在帮助初学者和进阶者掌握Python编程的各种方面。该文档在GitHub上非常受欢迎，包含了从安装Python到编写高质量代码、选择应用场景以及打包和部署代码的全方位指南。在“Getting Started”章节，文档首先介绍了如何选择和安装Python解释器。对于MacOSX用户，提供了详细的安装步骤；Windows用户可以了解到安装Python的具体过程；而对于Linux用户，文档也给出了相应的安装建议。 “Writing Great Code”章节深入讨论了编写优秀代码的方法。它强调了项目结构的重要性，讲解了如何合理组织你的项目。此外，本章还涵盖了代码风格，遵循PEP 8这一Python编码规范，以提高代码可读性和可维护性。阅读他人的优质代码也是提升自身技能的一种方式，文档推荐了一些值得参考的开源项目。编写代码的同时，文档还提到了文档编写的重要性，提倡使用docstrings和自动化文档工具。测试是保证代码质量的关键，文档中介绍了单元测试和集成测试的基本概念和工具。同时，列举了一些常见的编程陷阱，以避免在开发过程中遇到问题。最后，选择了合适的开源许可证，如MIT或Apache，可以保护你的代码并鼓励他人使用。 “Scenario Guide”章节针对不同类型的Python应用提供了指导。网络应用程序、Web应用、HTML抓取、命令行工具、图形用户界面（GUI）应用、数据库操作、网络编程、系统管理、持续集成、性能优化、科学计算、图像处理、XML解析以及密码学等方面都有所涉及，帮助开发者了解Python在这些领域的应用。 “Shipping Great Code”章节讲述了如何打包和分发你的Python项目。这包括将代码打包成可安装的轮子（wheel）或源码包，以及将Python应用程序“冻结”为独立的可执行文件，以便在没有Python环境的机器上运行。 “Development Environment”部分讨论了如何设置和优化开发环境，包括使用版本管理工具管理Python环境，以及虚拟环境的创建和使用，以确保项目的隔离和依赖管理。 “Additional Notes”章节提供了额外的信息，包括对Python社区的介绍，以及参与社区、贡献代码和获取帮助的途径。这份PythonGuide文档全面覆盖了从基础到高级的Python知识，是Python学习者的宝贵资源，无论你是初学者还是有经验的开发者，都能从中受益。

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 11

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

12 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 13

Python Guide Documentation, Release 0.0.1

it may be a good discipline to avoid assigning to a variable more than once, and it helps in grasping the concept of

mutable and immutable types.

2.1.7 Mutable and immutable types

Python has two kinds of built-in or user-deﬁned types.

Mutable types are those that allow in-place modiﬁcation of the content. Typical mutables are lists and dictionaries:

All lists have mutating methods, like list.append() or list.pop(), and can be modiﬁed in place. The same

goes for dictionaries.

Immutable types provide no method for changing their content. For instance, the variable x set to the integer 6 has no

“increment” method. If you want to compute x + 1, you have to create another integer and give it a name.

my_list = [1, 2, 3]

my_list[0] = 4

print my_list # [4, 2, 3] <- The same list as changed

x = 6

x = x + 1 # The new x is another object

One consequence of this difference in behavior is that mutable types are not “stable”, and therefore cannot be used as

dictionary keys.

Using properly mutable types for things that are mutable in nature and immutable types for things that are ﬁxed in

nature helps to clarify the intent of the code.

For example, the immutable equivalent of a list is the tuple, created with (1, 2). This tuple is a pair that cannot be

changed in-place, and can be used as a key for a dictionary.

One peculiarity of Python that can surprise beginners is that strings are immutable. This means that when constructing

a string from its parts, it is much more efﬁcient to accumulate the parts in a list, which is mutable, and then glue (‘join’)

the parts together when the full string is needed. One thing to notice, however, is that list comprehensions are better

and faster than constructing a list in a loop with calls to append().

Bad

# create a concatenated string from 0 to 19 (e.g. "012..1819")

nums = ""

for n in range(20):

nums += str(n) # slow and inefficient

print nums

Good

# create a concatenated string from 0 to 19 (e.g. "012..1819")

nums = []

for n in range(20):

nums.append(str(n))

print "".join(nums) # much more efficient

Best

# create a concatenated string from 0 to 19 (e.g. "012..1819")

nums = [str(n) for n in range(20)]

print "".join(nums)

One ﬁnal thing to mention about strings is that using join() is not always best. In the instances where you are

creating a new string from a pre-determined number of strings, using the addition operator is actually faster, but in

14 Chapter 2. Writing Great Code

剩余88页未读，继续阅读

ldjhust

粉丝: 1
资源: 11

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

python-guide, python 最佳实践指南，为人类编写.zip

python-guide python引言

python-guide.pdf

python 全栈开发/full-stack-python-guide-to-deployme

python-guide:python的样本

Python最佳实践指南 Python-Guide-CN-master.zip

python-guide Kenneth Reitz

Python-Guide-CN:“ Hitchhiker's Guide to Python”的汉语翻译

Learn-to-program-with-Python-guide:学习使用python 2.7编程的有用指南

python-guide:Python 新手指南 (Chinese Edition)

最新资源