1. 注释
在实际开发过程中, 代码源文件中除了代码外通常还有代码注释, 代码注释主要是为了方便后期的代码维护. 我们经常说自己写的代码过了几个月后再回来看时, 有时都不知道当时为什么要写这行代码、这个方法, 更何况是让别人来维护你的代码, 可以想象一下如果没有注释阅读代码将会是多么痛苦. 好的代码注释会让阅读者对代码的理解事半功倍, 所以你会发现, 不管什么编程语言, 都会有注释的存在
注释一般分为两种: 行注释和块注释
- python中的行注释
- 行注释以#号开头, 一直到该行结尾的内容都属于行注释的内容
- python中的块注释
- 块注释以"""或'''开头, """或'''结尾, 中间的内容属于块注释的内容, 注意需要开头和结尾符需要配套使用, 不能混合使用(即不能以"""开头, 以'''结尾)
#这是行注释, 从#号开头一直到本行结尾的内容都属于行注释的内容
num = 1
"""
这是块注释的第一种表示方法
以\"""开头和\"""结尾中间的内容都属于块注释的内容
"""
num = 1
'''
这是块注释的第二种表示方法
以\'''开头和\'''结尾中间的内容都属于块注释的内容
'''
num = 1
#下面的块注释是错误的
"""
开头和结尾必须配套使用, 不允许混合使用
'''
num = 1
2. coding: utf-8
这玩意干嘛的? 答案是: 用来定义源代码文件编码的
在python中, 默认源代码文件编码为Ascii码, 当我们源代码文件中出现中文字符时(不管是注释中出现中文, 还是代码字符串赋值时出现中文), 如果使用默认编码, 那么在执行时将会报错, 如下面代码, 在注释中出现了中文:
#这是行注释, 从#号开头一直到本行结尾的内容都属于行注释的内容
num = 1
那么在执行时, 将会提示如下错误:
File "test.py", line 1
SyntaxError: Non-ASCII character '\xd5' in file ttest.py on line 1, but no encoding declared; see http://python.org/dev/peps/pep-0263/ for details
错误提示中指出, 在test.py源文件中的第一行出现了非Ascii码字符但是没有给出编码声明, 并且给了一个url: PEP 263 -- Defining Python Source Code Encodings, 在该url中说如果要定义源代码文件编码可以通过两种形式:
- #coding=<encoding name
- - * - coding: <encoding name-*-
所以说, 当源码文件中出现了非Ascii编码字符时, 需要给出编码的方式, 而中文情况下, 我们通常会将编码方式设置为utf-8, 感兴趣的朋友可以自行查阅不同的编码方式之间的区别或者阅读字符编码: Ascii、GB2312、UTF-16、UTF-8这篇文章
当我们在源代码文件顶部声明了编码方式后, 再次执行时将不会提示错误
# -*- coding: utf-8 -*-
#这是行注释, 从#号开头一直到本行结尾的内容都属于行注释的内容
num = 1
3. 代码块(缩进)
一般其他编程语言像C/C++/java/golang等, 都是使用{}来标识代码块的, 而在python中, 代码块则是使用空格缩进的方式, 如果缩进缩错了将会导致最终结果也是错误的. 通常我们使用空格来缩进而不使用Tab键, 和语法相关的每一层缩进都用4个空格表示(使用TAB键需要设置TAB键的空格数目是4格)
# -*- coding: utf-8 -*-
#循环中的缩进
for i in range(1):
print 'Hello World'
#if else的缩进
if 1:
print 'Hello1'
else:
print 'Hello0'
#方法的缩进
def say_hello():
print 'hello'
4. 关键字
在刚开始学习python的时间, 了解python的关键字主要是为了在定义变量、方法、类时, 避免出现使用关键字当做变量、方法、类名的情况, 至于每个关键字所代表的含义, 随着学习的深入慢慢都会了解的
python2中的关键字列表:
print help("keywords") #可以通过该方法打印出python2中的关键字
and elif if print
as else import raise
assert except in return
break exec is try
class finally lambda while
continue for not with
def from or yield
del global pass
None
python3中的关键字列表:
#可以通过下面方法获取python3中的关键字
import keyword
print(keyword.kwlist)
False
None
True
and
as
assert
break
class
continue
def
del
elif
else
except
finally
for
from
global
if
import
in
is
lambda
nonlocal
not
or
pass
raise
return
try
while
with
yield
5. pythonic
这是个什么鬼? 其实具体我也说不清楚, 很多人都认同 Python之禅 中的描述:
#在源文件中输入下面的代码, 然后运行将会输出Python之禅的内容
import this
The Zen of Python, by Tim Peters
Beautiful is better than ugly.
优美胜于丑陋（Python以编写优美的代码为目标）
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.
不要包容所有错误，除非你确定需要这样做（精准地捕获异常，不写except:pass风格的代码）
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.
虽然这并不容易，因为你不是 Python 之父（这里的Dutch是指Guido）
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!
命名空间是一种绝妙的理念，我们应当多加利用（倡导与号召）
网友评论