#16862: merge with 3.3.
This commit is contained in:
commit
a2f959169a
|
@ -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
|
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
|
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
|
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
|
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
|
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>`_,
|
Answer 2: Fortunately, there is `Stackless Python <http://www.stackless.com>`_,
|
||||||
which has a completely redesigned interpreter loop that avoids the C stack.
|
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?
|
Why can't lambda forms contain statements?
|
||||||
|
@ -709,7 +706,7 @@ of each call to the function, and return the cached value if the same value is
|
||||||
requested again. This is called "memoizing", and can be implemented like this::
|
requested again. This is called "memoizing", and can be implemented like this::
|
||||||
|
|
||||||
# Callers will never provide a third parameter for this function.
|
# Callers will never provide a third parameter for this function.
|
||||||
def expensive (arg1, arg2, _cache={}):
|
def expensive(arg1, arg2, _cache={}):
|
||||||
if (arg1, arg2) in _cache:
|
if (arg1, arg2) in _cache:
|
||||||
return _cache[(arg1, arg2)]
|
return _cache[(arg1, arg2)]
|
||||||
|
|
||||||
|
@ -734,7 +731,7 @@ languages. For example::
|
||||||
|
|
||||||
try:
|
try:
|
||||||
...
|
...
|
||||||
if (condition): raise label() # goto label
|
if condition: raise label() # goto label
|
||||||
...
|
...
|
||||||
except label: # where to goto
|
except label: # where to goto
|
||||||
pass
|
pass
|
||||||
|
|
Loading…
Reference in New Issue