Merge pull request #344 from zlu27/developer

Update Chapter 01

source/c01/p01_unpack_sequence_into_separate_variables.rst

@@ -11,7 +11,7 @@
 解决方案
 ----------
 任何的序列（或者是可迭代对象）可以通过一个简单的赋值操作来分解为单独的变量。
-唯一的要求就是变量的总数和结构必须与序列相吻合。
+唯一的要求是，变量的总数和结构必须与序列保持一致。
 
 代码示例：
 
@@ -74,7 +74,7 @@
     'o'
     >>>
 
-有时候，你可能只想解压一部分，丢弃其他的值。对于这种情况 Python 并没有提供特殊的语法。
+有时候，你可能只想解压其中的一部分而丢弃其他的值。对于这种情况 Python 并没有提供特殊的语法。
 但是你可以使用任意变量名去占位，到时候丢掉这些变量就行了。
 
 代码示例：
@@ -89,4 +89,4 @@
     91.1
     >>>
 
-你必须保证你选用的那些占位变量名在其他地方没被使用到。
+但是，你必须保证你选用的那些占位变量名在其他地方没被使用到。

source/c01/p02_unpack_elements_from_iterables.rst

@@ -145,4 +145,4 @@ Python 的星号表达式可以用来解决这个问题。比如，你在学习
     >>>
 
 然后，由于语言层面的限制，递归并不是 Python 擅长的。
-因此，最后那个递归演示仅仅是个好奇的探索罢了，对这个不要太认真了。
+因此，最后那个递归演示仅仅是个好奇的探索罢了，别太较真。

source/c01/p03_keep_last_n_items.rst

@@ -86,4 +86,4 @@
     >>> q.popleft()
     4
 
-在队列两端插入或删除元素时间复杂度都是 ``O(1)`` ，区别于列表，在列表的开头插入或删除元素的时间复杂度为 ``O(N)`` 。
+在队列两端插入或删除元素的时间复杂度都是 ``O(1)`` 。列表则不同，在列表的开头插入或删除元素的时间复杂度是 ``O(N)`` 。

source/c01/p04_find_largest_or_smallest_n_items.rst

@@ -72,6 +72,6 @@ heapq 模块有两个函数：``nlargest()`` 和 ``nsmallest()`` 可以完美解
 需要在正确场合使用函数 ``nlargest()`` 和 ``nsmallest()`` 才能发挥它们的优势
 （如果 N 快接近集合大小了，那么使用排序操作会更好些）。
 
-尽管你没有必要一定使用这里的方法，但是堆数据结构的实现是一个很有趣并且值得你深入学习的东西。
+尽管你没有必要一定使用这里的方法，但是堆数据结构的实现很有趣，值得深入学习。
 基本上只要是数据结构和算法书籍里面都会有提及到。
 ``heapq`` 模块的官方文档里面也详细的介绍了堆数据结构底层的实现细节。

source/c01/p08_calculating_with_dict.rst

@@ -89,7 +89,7 @@
 这样的话你就能通过一条简单的语句就能很轻松的实现在字典上的求最值和排序操作了。
 
 需要注意的是在计算操作中使用到了 (值，键) 对。当多个实体拥有相同的值的时候，键会决定返回结果。
-比如，在执行 ``min()`` 和 ``max()`` 操作的时候，如果恰巧最小或最大值有重复的，那么拥有最小或最大键的实体会返回：
+比如，在执行 ``min()`` 和 ``max()`` 操作的时候，如果恰巧最小或最大值有重复的，则返回拥有最小或最大键的实体：
 
 .. code-block:: python
 

source/c01/p09_find_commonalities_in_dicts.rst

@@ -59,5 +59,5 @@
 这个对象同样也支持集合操作，并且可以被用来查找两个字典有哪些相同的键值对。
 
 尽管字典的 ``values()`` 方法也是类似，但是它并不支持这里介绍的集合操作。
-某种程度上是因为值视图不能保证所有的值互不相同，这样会导致某些集合操作出现问题。
-不过，如果你硬要在值上面执行这些集合操作的话，你可以先将值集合转换成 set，然后再执行集合运算就行了。
+某种程度上是因为值视图并不能保证所有的值互不相同，这样会导致某些集合操作出现问题。
+不过，如果你硬要在值上面执行这些集合操作的话，可以先将值集合转换成 set，然后再执行集合运算。

source/c01/p11_naming_slice.rst

@@ -32,8 +32,8 @@
 讨论
 ----------
 一般来讲，代码中如果出现大量的硬编码下标会使得代码的可读性和可维护性大大降低。
-比如，如果你回过来看看一年前你写的代码，你会摸着脑袋想那时候自己到底想干嘛啊。
-这是一个很简单的解决方案，它让你更加清晰的表达代码的目的。
+比如，如果你回过来看看一年前你写的代码，你会摸着脑袋想自己那时候到底在想什么啊。
+下面这个很简单的解决方案，可以让你更加清晰地表达代码的目的。
 
 内置的 ``slice()`` 函数创建了一个切片对象。所有使用切片的地方都可以使用切片对象。比如：
 
@@ -67,7 +67,7 @@
 
 另外，你还可以通过调用切片的 ``indices(size)`` 方法将它映射到一个已知大小的序列上。
 这个方法返回一个三元组 ``(start, stop, step)`` ，所有的值都会被缩小，直到适合这个已知序列的边界为止。
-这样，使用的时就不会出现 ``IndexError`` 异常。比如：
+（这样在使用的时就不会出现 ``IndexError`` 异常）。比如：
 
 .. code-block:: python
 

source/c01/p17_extract_subset_of_dict.rst

@@ -37,7 +37,7 @@
     p1 = dict((key, value) for key, value in prices.items() if value > 200)
 
 但是，字典推导方式表意更清晰，并且实际上也会运行的更快些
-（在这个例子中，实际测试几乎比 ``dict()`` 函数方式快整整一倍）。
+（在这个例子中，实际测试几乎比 ``dict()`` 函数方式快了一倍多）。
 
 有时候完成同一件事会有多种方式。比如，第二个例子程序也可以像这样重写：
 

source/c03/p14_date_range_for_current_month.rst

@@ -35,8 +35,8 @@
     >>> a_day = timedelta(days=1)
     >>> first_day, last_day = get_month_range()
     >>> while first_day < last_day:
-    ...     print(first_day)
-    ...     first_day += a_day
+    ...         print(first_day)
+    ...         first_day += a_day
     ...
     2012-08-01
     2012-08-02

source/c10/p03_import_submodules_by_relative_names.rst

@@ -59,7 +59,7 @@
     from . import grok # OK
     import grok # Error (not found)
 
-像mypackage.A这样使用绝对路径名的不利之处是这将顶层包名硬编码到你的源码中。如果你想重新组织它，你的代码将更脆，很难工作。 举个例子，如果你改变了包名，你就必须检查所有文件来修正源码。 同样，硬编码的名称会使移动代码变得困难。举个例子，也许有人想安装两个不同版本的软件包，只通过名称区分它们。 如果使用相对导入，那一切都ok，然而使用绝对路径名很可能会出问题。
+类似于mypackage.A这样使用绝对路径名的缺点是，它会把顶层包名硬编码到源码中。如果你想重新组织它，那就适得其反——你的代码会更为脆弱，难以运作。 举例来说，如果你改变了包名，你想要修正源码就必须检查所有文件来。 同样，硬编码的名称会使移动代码变得困难。举个例子，也许有人想安装两个不同版本的软件包，只通过名称区分它们。 如果使用相对导入，那一切都ok，然而使用绝对路径名很可能会出问题。
 
 
 import语句的 ``.`` 和 ``..`` 看起来很滑稽, 但它指定目录名.为当前目录，..B为目录../B。这种语法只适用于import。

source/c15/p11_use_cython_to_write_high_performance_array_operation.rst

@@ -103,7 +103,7 @@
     3.760528204000366
     >>>
 
-正如你看到的，它要快很多——这是一个很有趣的结果，因为NumPy版本的核心代码还是用C语言写的。
+如你所见，它快了一些——考虑到NumPy版本的核心代码是用C语言写的，这还挺有趣。
 
 ----------
 讨论