#16862: merge with 3.2.
This commit is contained in:
commit
9f6a239cf1
|
@ -214,7 +214,7 @@ The major reason is history. Functions were used for those operations that were
|
|||
generic for a group of types and which were intended to work even for objects
|
||||
that didn't have methods at all (e.g. tuples). It is also convenient to have a
|
||||
function that can readily be applied to an amorphous collection of objects when
|
||||
you use the functional features of Python (``map()``, ``apply()`` et al).
|
||||
you use the functional features of Python (``map()``, ``zip()`` et al).
|
||||
|
||||
In fact, implementing ``len()``, ``max()``, ``min()`` as a built-in function is
|
||||
actually less code than implementing them as methods for each type. One can
|
||||
|
@ -345,9 +345,6 @@ support for C.
|
|||
|
||||
Answer 2: Fortunately, there is `Stackless Python <http://www.stackless.com>`_,
|
||||
which has a completely redesigned interpreter loop that avoids the C stack.
|
||||
It's still experimental but looks very promising. Although it is binary
|
||||
compatible with standard Python, it's still unclear whether Stackless will make
|
||||
it into the core -- maybe it's just too revolutionary.
|
||||
|
||||
|
||||
Why can't lambda forms contain statements?
|
||||
|
@ -734,7 +731,7 @@ languages. For example::
|
|||
|
||||
try:
|
||||
...
|
||||
if (condition): raise label() # goto label
|
||||
if condition: raise label() # goto label
|
||||
...
|
||||
except label: # where to goto
|
||||
pass
|
||||
|
|
Loading…
Reference in New Issue