已故的英國哲學家菲利帕‧福特 Philippa Foot，她於一九六七年發表了一篇名為《堕胎問题和教條雙重影響》論文，當中提出了『電車問題』，用来『批判』時下倫理哲學中之主流思想，尤其是功利主義的觀點︰
大部分之道德判斷都是依據『為最多的人謀取最大之利益』的原则而決定的。
她的原文引用如下︰
Suppose that a judge or magistrate is faced with rioters demanding that a culprit be found guilty for a certain crime and threatening otherwise to take their own bloody revenge on a particular section of the community. The real culprit being unknown, the judge sees himself as able to prevent the bloodshed only by framing some innocent person and having him executed.
Beside this example is placed another in which a pilot whose aeroplane is about to crash is deciding whether to steer from a more to a less inhabited area.
To make the parallel as close as possible it may rather be supposed that he is the driver of a runaway tram which he can only steer from one narrow track on to another; five men are working on one track and one man on the other; anyone on the track he enters is bound to be killed. In the case of the riots the mob have five hostages, so that in both examples the exchange is supposed to be one man’s life for the lives of five.
設想一個法官或推事正面對著暴徒的要求，有個罪犯必須為某犯行認罪服法，否則他們將自行報復血洗這個社區的特定區域。然而真正的犯行者未明，法官觀察到自己似能阻止這場血洗，只要將無辜者框陷處決就好。
除了這個例子之外，另一就是︰一位即將墬機的飛行員要如何決定導向哪個較多還是較少人居住的地方呢。
為了盡可能平行立論，就這樣假想吧︰某人駕駛一輛即將出軌的火車，他僅能從這一窄軌導向另一窄軌；一邊有五人正在軌上工作，另一軌上有一人；不論他進入何軌，那軌道上的人全都必死無疑。好比暴動中一暴民挾持五位人質一樣，當下的兩個例子中都是如此假設一命與五命之兌換。
這個倫理學之『難題』現今有許多不同的類似之『版本』，也許是因為它是這個領域中最為知名的『思想實驗』之一的罷！！
美籍匈牙利的大數學家 George Pólya 寫過一本《怎樣解題》的書，書中強調解題的『第一步』是『了解問題』是什麼？問題的『限制條件』又是什麼？『概念定義』有沒有『歧義』？能不能『改寫重述』這個問題的呢？如果『解題者』能這樣作，那就是『思過半已』。
我們就跟隨波利亞的『金科玉律』，先了解這個問題是什麼？如果從福特女士的說法來看，這是一個『選擇的道德性』、『行為的正義性』和『道德正義能不能有量與質的比較之尺』的相關之『問題』 。由於她並沒有說明與提起『 □ □ 性』或是定義『 ○○ 質』，我們也只能用『歷史 』以來的『思想』假定她說的『理念』和『爭議』。這樣提出以下的『模型』以及『說明』，這個『目的』是期望能『釐清分辨』所論所指。
首先作者將界定若干『術語』，方便談論著這些『語詞』的意義到底是什麼？人們又或是『同意』或者是『不同意』？
人之各種活動至少包含了『思維』與『作為』，我們就簡單截斷的說『行為』是『行動』的『論域』，它還包括著『想而不作』之『不作為』，就是說︰
行為 = Behavior = B = { 行動 } 
{不作為}
人都有『抉擇』的『自由』，稱之為『自由意志』；在任何情況下得為自己的『行為』來『負責』，或者可能因為這個選擇而產生『愧疚』，但是它也有『不抉擇』的自由︰
自由意志 = Free will = F = {抉擇} {不抉擇}
，因此『責任』、『權利』、『義務』、『犧牲』或『奉獻』…等等，都是『定義』在 
『人事物』上的某種『關係』 
。
道德判斷 
或公平正義 
都是一種『行為』或與『選擇』的『度量』，它至少『分別』著，『有善、好』、『有惡、壞』和『好壞、善惡无記』。然而這兩者到底是具有『試金石』，『甜度計』還是『度量衡』之某類事物的性質，不同的『權衡理論』之『判準』不同。也就是說 和 都是『特定理論』之某類的『函數』，或許相互彼此得由『大同小異』或『求同存異』來『定奪』是非。
人類的歷史上古往今來有一個『信念』的『通則』是︰
凡事若是不道德，皆不可作此選擇，也都不應當作為。
就讓我們『重述』這個『電車問題』如下︰
有些人相信且認為有一根可以『量化道德』之尺的存在，他們在一般的『抉擇情境』下，也會同意這裡『所列舉之選項』是『不道德的』並且不符合於『公平正義』之通則，即使處於此種『特殊情境』之下，也許他們也還是同意著上述的通則，只不過他們卻是用著『數量大小的比較可以得出好壞之高低』的判斷來決定著『善惡』之分界，但是這種『多寡區分』應該是不可能改變『性質分辨』之什麼的吧？？
假使這已然是個真實的『面對』情境，也許一人說︰
既然『道德』的理想已不可能，就用『善惡』的實際吧，要是依舊無法達到，只得按造『好壞』的現實 了，終究『兩利相權，取其重；兩害相衡，取其輕』。
或許另一人講︰
縱使願意自我『犧牲』，依然不能『兩全』，又有誰知『今日之選擇』不是『來日之因果』的呢？更不必說果真有個『選擇的利弊得失』的計較嗎？不如就『擲個銅板』吧！反正人生自古誰無死！該誰的就各安天命吧！！還是終得自己面對無盡的『無奈』。
─── 《電車問題 ── THUE 改寫系統之補充《一》》
博大之人文『理念』靠語言『傳播』，精深的科技『知識』賴文字『傳達』◎
欲將 Scapy 『中文化』，自得使用派生三 python3 『萬國瑪』哩。由於
PEP 3113 — Removal of Tuple Parameter Unpacking
| PEP: | 3113 |
|---|---|
| Title: | Removal of Tuple Parameter Unpacking |
| Author: | Brett Cannon <brett at python.org> |
| Status: | Final |
| Type: | Standards Track |
| Created: | 02-Mar-2007 |
| Python-Version: | 3.0 |
| Post-History: |
Contents
之決定︰
Abstract
Tuple parameter unpacking is the use of a tuple as a parameter in a function signature so as to have a sequence argument automatically unpacked. An example is:
def fxn(a, (b, c), d):
pass
The use of (b, c) in the signature requires that the second argument to the function be a sequence of length two (e.g., [42,-13]). When such a sequence is passed it is unpacked and has its values assigned to the parameters, just as if the statement b, c = [42, -13] had been executed in the parameter.
Unfortunately this feature of Python’s rich function signature abilities, while handy in some situations, causes more issues than they are worth. Thus this PEP proposes their removal from the language in Python 3.0.
Why They Should Go
Introspection Issues
Python has very powerful introspection capabilities. These extend to function signatures. There are no hidden details as to what a function’s call signature is. In general it is fairly easy to figure out various details about a function’s signature by viewing the function object and various attributes on it (including the function’s func_code attribute).
But there is great difficulty when it comes to tuple parameters. The existence of a tuple parameter is denoted by its name being made of a . and a number in the co_varnames attribute of the function’s code object. This allows the tuple argument to be bound to a name that only the bytecode is aware of and cannot be typed in Python source. But this does not specify the format of the tuple: its length, whether there are nested tuples, etc.
In order to get all of the details about the tuple from the function one must analyse the bytecode of the function. This is because the first bytecode in the function literally translates into the tuple argument being unpacked. Assuming the tuple parameter is named .1 and is expected to unpack to variables spam and monty (meaning it is the tuple (spam, monty)), the first bytecode in the function will be for the statement spam, monty = .1. This means that to know all of the details of the tuple parameter one must look at the initial bytecode of the function to detect tuple unpacking for parameters formatted as \.\d+ and deduce any and all information about the expected argument. Bytecode analysis is how the inspect.getargspec function is able to provide information on tuple parameters. This is not easy to do and is burdensome on introspection tools as they must know how Python bytecode works (an otherwise unneeded burden as all other types of parameters do not require knowledge of Python bytecode).
The difficulty of analysing bytecode not withstanding, there is another issue with the dependency on using Python bytecode. IronPython [3] does not use Python’s bytecode. Because it is based on the .NET framework it instead stores MSIL [4] infunc_code.co_code attribute of the function. This fact prevents the inspect.getargspec function from working when run under IronPython. It is unknown whether other Python implementations are affected but is reasonable to assume if the implementation is not just a re-implementation of the Python virtual machine.
No Loss of Abilities If Removed
As mentioned in Introspection Issues, to handle tuple parameters the function’s bytecode starts with the bytecode required to unpack the argument into the proper parameter names. This means that there is no special support required to implement tuple parameters and thus there is no loss of abilities if they were to be removed, only a possible convenience (which is addressed in Why They Should (Supposedly) Stay).
The example function at the beginning of this PEP could easily be rewritten as:
def fxn(a, b_c, d):
b, c = b_c
pass
and in no way lose functionality.
Exception To The Rule
When looking at the various types of parameters that a Python function can have, one will notice that tuple parameters tend to be an exception rather than the rule.
Consider PEP 3102 (keyword-only arguments) and PEP 3107 (function annotations) [5] [6]. Both PEPs have been accepted and introduce new functionality within a function’s signature. And yet for both PEPs the new feature cannot be applied to tuple parameters as a whole. PEP 3102 has no support for tuple parameters at all (which makes sense as there is no way to reference a tuple parameter by name). PEP 3107 allows annotations for each item within the tuple (e.g., (x:int, y:int)), but not the whole tuple (e.g., (x, y):int).
The existence of tuple parameters also places sequence objects separately from mapping objects in a function signature. There is no way to pass in a mapping object (e.g., a dict) as a parameter and have it unpack in the same fashion as a sequence does into a tuple parameter.
造成派生三與派生二『文法』不同也︰
自當『改寫』呦☆
