|
Original |
Translation |
|
70
|
You can do this easily enough with a sequence of ``if... elif... elif... else``. There have been some proposals for switch statement syntax, but there is no consensus (yet) on whether and how to do range tests. See :pep:`275` for complete details and the current status.
|
|
|
71
|
For cases where you need to choose from a very large number of possibilities, you can create a dictionary mapping case values to functions to call. For example::
|
|
|
72
|
def function_1(...): ... functions = {'a': function_1, 'b': function_2, 'c': self.method_1, ...} func = functions[value] func()
|
|
|
73
|
For calling methods on objects, you can simplify yet further by using the :func:`getattr` built-in to retrieve methods with a particular name::
|
|
|
74
|
|
75
|
It's suggested that you use a prefix for the method names, such as ``visit_`` in this example. Without such a prefix, if values are coming from an untrusted source, an attacker would be able to call any method on your object.
|
|
|
76
|
Can't you emulate threads in the interpreter instead of relying on an OS-specific thread implementation?
|
|
|
77
|
Answer 1: Unfortunately, the interpreter pushes at least one C stack frame for each Python stack frame. Also, extensions can call back into Python at almost random moments. Therefore, a complete threads implementation requires thread support for C.
|
|
|
78
|
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.
|
|
|
79
|
Why can't lambda forms contain statements?
|
|