注册 登录  
 加关注
   显示下一条  |  关闭
温馨提示!由于新浪微博认证机制调整,您的新浪微博帐号绑定已过期,请重新绑定!立即重新绑定新浪微博》  |  关闭

phperwuhan的博客

记载一个phper的历程!phperwuhan.blog.163.com

 
 
 

日志

 
 

python独特点  

2009-10-28 10:27:15|  分类: python |  标签: |举报 |字号 订阅

  下载LOFTER 我的照片书  |

来源:http://www.woodpecker.org.cn:9081/doc/abyteofpython_cn/chinese/ch04s08.html

http://www.woodpecker.org.cn:9081/doc/abyteofpython_cn/chinese/ch04s09.html

http://www.woodpecker.org.cn:9081/doc/abyteofpython_cn/chinese/ch05s04.html

http://www.python.org/dev/peps/pep-0263/

http://www.woodpecker.org.cn:9081/doc/abyteofpython_cn/chinese/ch06s05.html

http://www.woodpecker.org.cn:9081/doc/abyteofpython_cn/chinese/ch07s03.html

http://www.woodpecker.org.cn:9081/doc/abyteofpython_cn/chinese/ch07s04.html

逻辑行与物理行

物理行是你在编写程序时所 看见 的。逻辑行是Python 看见 的单个语句。Python假定每个 物理行 对应一个 逻辑行

逻辑行的例子如

print 'Hello World'

这样的语句——如果它本身就是一行(就像你在编辑器中看到的那样),那么它也是一个物理行。

默认地,Python希望每行都只使用一个语句,这样使得代码更加易读。

如果你想要在一个物理行中使用多于一个逻辑行,那么你需要使用分号(;)来特别地标明这种用法。分号表示一个逻辑行/语句的结束。例如:

i =

5

print

i

与下面这个相同:

i =

5

;

print

i

;

同样也可以写成:

i =

5

;

print

i

;

甚至可以写成:

i =

5

;

print

i

然而,我强烈建议你坚持在每个物理行只写一句逻辑行。仅仅当逻辑行太长的时候,在多于一个物理行写一个逻辑行。这些都是为了尽可能避免使用分号,从而让代码更加易读。事实上,我 从来没有 在Python程序中使用过或看到过分号。

下面是一个在多个物理行中写一个逻辑行的例子。它被称为明确的行连接。

s =

'This is a string. \

This continues the string.'

print

s

它的输出:

This is a string. This continues the string.

类似地,

print

\

i

与如下写法效果相同:

print

i

有时候,有一种暗示的假设,可以使你不需要使用反斜杠。这种情况出现在逻辑行中使用了圆括号、方括号或波形括号的时候。这被称为暗示的行连接。你会在后面介绍如何使用列表的章节中看到这种用法。

 

缩进

空白在Python中是重要的。事实上行首的空白是重要的。它称为缩进。在逻辑行首的空白(空格和制表符)用来决定逻辑行的缩进层次,从而用来决定语句的分组。

这意味着同一层次的语句必须有相同的缩进。每一组这样的语句称为一个块。我们将在后面的章节中看到有关块的用处的例子。

你需要记住的一样东西是错误的缩进会引发错误。例如:

i =

5

 

print

'Value is'

, i

# Error! Notice a single space at the start of the line

print

'I repeat, the value is'

, i

当你运行这个程序的时候,你会得到下面的错误:

  File "whitespace.py", line 4

    print 'Value is', i # Error! Notice a single space at the start of the line

    ^

SyntaxError: invalid syntax

注意,在第二行的行首有一个空格。Python指示的这个错误告诉我们程序的语法是无效的,即程序没有正确地编写。它告诉你, 你不能随意地开始新的语句块 (当然除了你一直在使用的主块)。何时你能够使用新块,将会在后面的章节,如控制流中详细介绍。

如何缩进

不要混合使用制表符和空格来缩进,因为这在跨越不同的平台的时候,无法正常工作。我 强烈建议 你在每个缩进层次使用 单个制表符两个或四个空格

选择这三种缩进风格之一。更加重要的是,选择一种风格,然后一贯地使用它,即 使用这一种风格。

 

 

表达式

code/expression.py

输出

$ python expression.py

Area is 10

Perimeter is 14

它如何工作

矩形的长度与宽度存储在以它们命名的变量中。我们借助表达式使用它们计算矩形的面积和边长。我们表达式

length * breadth

的结果存储在变量

area

中,然后用

print

语句打印。在另一个打印语句中,我们直接使用表达式

2 * (length + breadth)

的值。

另外,注意Python如何打印“漂亮的”输出。尽管我们没有在

'Area is'

和变量

area

之间指定空格,Python自动在那里放了一个空格,这样我们就可以得到一个清晰漂亮的输出,而程序也变得更加易读(因为我们不需要担心输出之间的空格问题)。这是Python如何使程序员的生活变得更加轻松的一个例子。

 

源文件编码定义:

PEP:  0263
Title:  Defining Python Source Code Encodings
Version:  73234
Last-Modified:  2009-06-04 21:44:37 +0200 (Thu, 04 Jun 2009)
Author:  Marc-André Lemburg <mal at lemburg.com>, Martin von Löwis <martin at v.loewis.de>
Status:  Final
Type:  Standards Track
Created:  06-Jun-2001
Python-Version:  2.3
Post-History: 

Abstract

    This PEP proposes to introduce a syntax to declare the encoding of      a Python source file. The encoding information is then used by the      Python parser to interpret the file using the given encoding. Most      notably this enhances the interpretation of Unicode literals in      the source code and makes it possible to write Unicode literals      using e.g. UTF-8 directly in an Unicode aware editor.    

Problem

    In Python 2.1, Unicode literals can only be written using the      Latin-1 based encoding "unicode-escape". This makes the      programming environment rather unfriendly to Python users who live      and work in non-Latin-1 locales such as many of the Asian       countries. Programmers can write their 8-bit strings using the      favorite encoding, but are bound to the "unicode-escape" encoding      for Unicode literals.    

Proposed Solution

    I propose to make the Python source code encoding both visible and      changeable on a per-source file basis by using a special comment      at the top of the file to declare the encoding.        To make Python aware of this encoding declaration a number of      concept changes are necessary with respect to the handling of      Python source code data.    

Defining the Encoding

    Python will default to ASCII as standard encoding if no other      encoding hints are given.        To define a source code encoding, a magic comment must      be placed into the source files either as first or second      line in the file, such as:              # coding=<encoding name>        or (using formats recognized by popular editors)              #!/usr/bin/python            # -*- coding: <encoding name> -*-        or              #!/usr/bin/python            # vim: set fileencoding=<encoding name> :        More precisely, the first or second line must match the regular      expression "coding[:=]\s*([-\w.]+)". The first group of this      expression is then interpreted as encoding name. If the encoding      is unknown to Python, an error is raised during compilation. There      must not be any Python statement on the line that contains the      encoding declaration.        To aid with platforms such as Windows, which add Unicode BOM marks      to the beginning of Unicode files, the UTF-8 signature      '\xef\xbb\xbf' will be interpreted as 'utf-8' encoding as well      (even if no magic encoding comment is given).        If a source file uses both the UTF-8 BOM mark signature and a      magic encoding comment, the only allowed encoding for the comment      is 'utf-8'.  Any other encoding will cause an error.    

Examples

    These are some examples to clarify the different styles for      defining the source code encoding at the top of a Python source      file:        1. With interpreter binary and using Emacs style file encoding         comment:              #!/usr/bin/python            # -*- coding: latin-1 -*-            import os, sys            ...              #!/usr/bin/python            # -*- coding: iso-8859-15 -*-            import os, sys            ...              #!/usr/bin/python            # -*- coding: ascii -*-            import os, sys            ...        2. Without interpreter line, using plain text:              # This Python file uses the following encoding: utf-8            import os, sys            ...        3. Text editors might have different ways of defining the file's         encoding, e.g.              #!/usr/local/bin/python            # coding: latin-1            import os, sys            ...        4. Without encoding comment, Python's parser will assume ASCII         text:              #!/usr/local/bin/python            import os, sys            ...        5. Encoding comments which don't work:           Missing "coding:" prefix:              #!/usr/local/bin/python            # latin-1            import os, sys            ...           Encoding comment not on line 1 or 2:              #!/usr/local/bin/python            #            # -*- coding: latin-1 -*-            import os, sys            ...           Unsupported encoding:              #!/usr/local/bin/python            # -*- coding: utf-42 -*-            import os, sys            ...    

Concepts

    The PEP is based on the following concepts which would have to be      implemented to enable usage of such a magic comment:        1. The complete Python source file should use a single encoding.         Embedding of differently encoded data is not allowed and will         result in a decoding error during compilation of the Python         source code.           Any encoding which allows processing the first two lines in the         way indicated above is allowed as source code encoding, this         includes ASCII compatible encodings as well as certain         multi-byte encodings such as Shift_JIS. It does not include         encodings which use two or more bytes for all characters like         e.g. UTF-16. The reason for this is to keep the encoding         detection algorithm in the tokenizer simple.        2. Handling of escape sequences should continue to work as it does          now, but with all possible source code encodings, that is         standard string literals (both 8-bit and Unicode) are subject to          escape sequence expansion while raw string literals only expand         a very small subset of escape sequences.        3. Python's tokenizer/compiler combo will need to be updated to         work as follows:           1. read the file           2. decode it into Unicode assuming a fixed per-file encoding           3. convert it into a UTF-8 byte string           4. tokenize the UTF-8 content           5. compile it, creating Unicode objects from the given Unicode data            and creating string objects from the Unicode literal data            by first reencoding the UTF-8 data into 8-bit string data            using the given file encoding           Note that Python identifiers are restricted to the ASCII         subset of the encoding, and thus need no further conversion         after step 4.    

Implementation

    For backwards-compatibility with existing code which currently      uses non-ASCII in string literals without declaring an encoding,      the implementation will be introduced in two phases:        1. Allow non-ASCII in string literals and comments, by internally         treating a missing encoding declaration as a declaration of         "iso-8859-1". This will cause arbitrary byte strings to         correctly round-trip between step 2 and step 5 of the         processing, and provide compatibility with Python 2.2 for         Unicode literals that contain non-ASCII bytes.           A warning will be issued if non-ASCII bytes are found in the         input, once per improperly encoded input file.        2. Remove the warning, and change the default encoding to "ascii".        The builtin compile() API will be enhanced to accept Unicode as      input. 8-bit string input is subject to the standard procedure for      encoding detection as described above.        If a Unicode string with a coding declaration is passed to compile(),      a SyntaxError will be raised.        SUZUKI Hisao is working on a patch; see [2] for details. A patch      implementing only phase 1 is available at [1].    

Phases

    Implementation of steps 1 and 2 above were completed in 2.3,      except for changing the default encoding to "ascii".        The default encoding was set to "ascii" in version 2.5.       

Scope

    This PEP intends to provide an upgrade path from the current      (more-or-less) undefined source code encoding situation to a more      robust and portable definition.    

References

    [1] Phase 1 implementation:          http://python.org/sf/526840      [2] Phase 2 implementation:          http://python.org/sf/534304    

History

    1.10 and above: see CVS history      1.8: Added '.' to the coding RE.      1.7: Added warnings to phase 1 implementation. Replaced the           Latin-1 default encoding with the interpreter's default           encoding. Added tweaks to compile().      1.4 - 1.6: Minor tweaks      1.3: Worked in comments by Martin v. Loewis:            UTF-8 BOM mark detection, Emacs style magic comment,           two phase approach to the implementation    

Copyright

    This document has been placed in the public domain.  

 

 

 

for循环

for..in

是另外一个循环语句,它在一序列的对象上 递归 即逐一使用队列中的每个项目。我们会在后面的章节中更加详细地学习序列

break语句。

记住,

for..in

循环对于任何序列都适用。这里我们使用的是一个由内建

range

函数生成的数的列表,但是广义说来我们可以使用任何种类的由任何对象组成的序列!我们会在后面的章节中详细探索这个观点。

给C/C++/Java/C#程序员的注释

Python的

for

循环从根本上不同于C/C++的

for

循环。C#程序员会注意到Python的

for

循环与C#中的

foreach

循环十分类似。Java程序员会注意到它与Java 1.5中的

for (int i : IntArray)

相似。

在C/C++中,如果你想要写

for (int i = 0; i < 5; i++)

,那么用Python,你写成

for i in range(0,5)

。你会注意到,Python的

for

循环更加简单、明白、不易出错。

 

break语句

DE>breakDE>语句是用来 终止 循环语句的,即哪怕循环条件没有称为DE>FalseDE>或序列还没有被完全递归,也停止执行循环语句。

一个重要的注释是,如果你从DE>forDE>或DE>whileDE>循环中 终止 ,任何对应的循环DE>elseDE>块将执行。

 

 

局部变量

当你在函数定义内声明变量的时候,它们与函数外具有相同名称的其他变量没有任何关系,即变量名称对于函数来说是 局部 的。这称为变量的 作用域 。所有变量的作用域是它们被定义的块,从它们的名称被定义的那点开始。

code/func_local.py

输出

$ python func_local.py

x is 50

Changed local x to 2

x is still 50

它如何工作

在函数中,我们第一次使用

x

的时候,Python使用函数声明的形参的值。

接下来,我们把值

2

赋给

x

x

是函数的局部变量。所以,当我们在函数内改变

x

的值的时候,在主块中定义的

x

不受影响。

在最后一个

print

语句中,我们证明了主块中的

x

的值确实没有受到影响。

code/func_global.py

输出

$ python func_global.py

x is 50

Changed global x to 2

Value of x is 2

它如何工作

global

语句被用来声明

x

是全局的——因此,当我们在函数内把值赋给

x

的时候,这个变化也反映在我们在主块中使用

x

的值的时候。

你可以使用同一个

global

语句指定多个全局变量。例如

global x, y, z

 

 

 

 

默认参数值

对于一些函数,你可能希望它的一些参数是 可选 的,如果用户不想要为这些参数提供值的话,这些参数就使用默认值。这个功能借助于默认参数值完成。你可以在函数定义的形参名后加上赋值运算符(=)和默认值,从而给形参指定默认参数值。

注意,默认参数值应该是一个参数。更加准确的说,默认参数值应该是不可变的——这会在后面的章节中做详细解释。从现在开始,请记住这一点。

使用默认参数值

例7.5 使用默认参数值

DE<#!/usr/bin/python
# Filename: func_default.pyDE<

DE<def DE<DE<sayDE<DE<(message, times = DE<DE<1DE<DE<):DE<
DE<    print DE<DE<message * timesDE<

DE<say(DE<DE<'Hello'DE<DE<)DE<
DE<say(DE<DE<'World'DE<DE<, DE<DE<5DE<DE<)DE<

(源文件:code/func_default.py

输出

DE<$ python func_default.py
Hello
WorldWorldWorldWorldWorld DE<

它如何工作

名为DE<sayDE<的函数用来打印一个字符串任意所需的次数。如果我们不提供一个值,那么默认地,字符串将只被打印一遍。我们通过给形参DE<timesDE<指定默认参数值DE<1DE<来实现这一功能。

在第一次使用DE<sayDE<的时候,我们只提供一个字符串,函数只打印一次字符串。在第二次使用DE<sayDE<的时候,我们提供了字符串和参数DE<5DE<,表明我们想要 这个字符串消息5遍。

重要
只有在形参表末尾的那些参数可以有默认参数值,即你不能在声明函数形参的时候,先声明有默认值的形参而后声明没有默认值的形参。
这是因为赋给形参的值是根据位置而赋值的。例如,DE<def func(a, b=5)DE<是有效的,但是DE<def func(a=5, b)DE<是 无效 的。

  评论这张
 
阅读(552)| 评论(0)
推荐 转载

历史上的今天

在LOFTER的更多文章

评论

<#--最新日志,群博日志--> <#--推荐日志--> <#--引用记录--> <#--博主推荐--> <#--随机阅读--> <#--首页推荐--> <#--历史上的今天--> <#--被推荐日志--> <#--上一篇,下一篇--> <#-- 热度 --> <#-- 网易新闻广告 --> <#--右边模块结构--> <#--评论模块结构--> <#--引用模块结构--> <#--博主发起的投票-->
 
 
 
 
 
 
 
 
 
 
 
 
 
 

页脚

网易公司版权所有 ©1997-2017