diff --git a/faq/design.po b/faq/design.po index be9ad54c21..97ad2b7df2 100644 --- a/faq/design.po +++ b/faq/design.po @@ -9,7 +9,7 @@ msgstr "" "Project-Id-Version: Python 3.10\n" "Report-Msgid-Bugs-To: \n" "POT-Creation-Date: 2022-07-06 00:17+0000\n" -"PO-Revision-Date: 2018-05-23 14:35+0000\n" +"PO-Revision-Date: 2022-08-29 22:27+0800\n" "Last-Translator: Adrian Liaw \n" "Language-Team: Chinese - TAIWAN (https://github.com/python/python-docs-zh-" "tw)\n" @@ -18,10 +18,12 @@ msgstr "" "Content-Type: text/plain; charset=UTF-8\n" "Content-Transfer-Encoding: 8bit\n" "Plural-Forms: nplurals=1; plural=0;\n" +"X-Generator: Poedit 3.1.1\n" +"X-Poedit-Bookmarks: -1,-1,-1,-1,-1,93,25,-1,-1,-1\n" #: ../../faq/design.rst:3 msgid "Design and History FAQ" -msgstr "設計和歷史常見問題" +msgstr "設計和歷史常見問答集" #: ../../faq/design.rst:6 msgid "Contents" @@ -58,9 +60,10 @@ msgid "" "will sometimes stare at it a long time wondering as to why ``y`` is being " "decremented even for ``x > y``." msgstr "" -"若陳述為真,則只有 ``x++`` 會執行,但縮排讓很多人誤會意思不是這樣。" -"即便是經驗豐富的 C 語言程式設計師,有時也會盯著螢幕良久,思考為什麼即便是 ``x > y``" -"的時候 ``y`` 也會減少。" +"如果條件為真,只有 ``x++`` 陳述式會被執行,但縮排會讓很多人對他有不同的理解。" +"即使是資深的 C 語言開發者有時也會盯著他許久,思考為何即便 ``x > y``\\ ,但 " +"``y`` 還是減少了。" + #: ../../faq/design.rst:31 msgid "" @@ -70,6 +73,9 @@ msgid "" "is normal to feel somewhat uneasy when reading (or being required to write) " "in a different one." msgstr "" +"因為沒有開頭與結尾的括號,Python 比起其他語言會更不容易遇到程式碼風格的衝突。" +"在 C 語言中,有多種不同的方法來放置花括號。在習慣讀寫特定風格後,去讀(或是必" +"須去寫)另一種風格會覺得不太舒服。" #: ../../faq/design.rst:38 msgid "" @@ -81,6 +87,11 @@ msgid "" "brackets -- the lack of declarations and the high-level data types are also " "responsible -- but the indentation-based syntax certainly helps." msgstr "" +"很多程式碼風格會把 begin/end 獨立放在一行。這會讓程式碼很長且浪費珍貴的螢幕空" +"間,要概覽程式時也變得較為困難。理想上來說,一個函式應該要佔一個螢幕(大概 " +"20 至 30 行)。20 行的 Python 程式碼比起 20 行的 C 程式碼可以做更多事。雖然沒" +"有開頭與結尾的括號並非單一原因(沒有變數宣告及高階的資料型別同樣有關),但縮排式的" +"語法確實給了幫助。" #: ../../faq/design.rst:48 msgid "Why am I getting strange results with simple arithmetic operations?" @@ -92,7 +103,7 @@ msgstr "請見下一個問題。" #: ../../faq/design.rst:54 msgid "Why are floating-point calculations so inaccurate?" -msgstr "為何浮點數運算如此不精確?" +msgstr "為何浮點數運算如此不精確?" #: ../../faq/design.rst:56 msgid "Users are often surprised by results like this::" @@ -106,6 +117,8 @@ msgid "" "Python, and much more to do with how the underlying platform handles " "floating-point numbers." msgstr "" +"然後認為這是 Python 的 bug,但這並不是。這跟 Python 幾乎沒有關係,而是和底層" +"如何處理浮點數有關係。" #: ../../faq/design.rst:65 msgid "" @@ -116,12 +129,20 @@ msgid "" "point operations. This means that as far as floating-point operations are " "concerned, Python behaves like many popular languages including C and Java." msgstr "" +"CPython 的 :class:`float` 型別使用了 C 的 ``double`` 型別來儲存。一個 :class:" +"`float` 物件的值會以固定的精度(通常為 53 位元)存為二進制浮點數,Python 使" +"用 C 來運算浮點數,而他的結果會依處理器中的硬體實作方式來決定。這表示就浮點數" +"運算來說,Python 和 C、Java 等很多受歡迎的語言有一樣的行為。" #: ../../faq/design.rst:72 msgid "" "Many numbers that can be written easily in decimal notation cannot be " "expressed exactly in binary floating-point. For example, after::" msgstr "" +"很多數字可以簡單地寫成十進位表示,但卻無法簡單地變成二進制表示。比方說,在以" +"下程式碼執行後:\n" +"\n" +"::" #: ../../faq/design.rst:77 msgid "" @@ -129,26 +150,35 @@ msgid "" "value ``1.2``, but is not exactly equal to it. On a typical machine, the " "actual stored value is::" msgstr "" +"``x`` 裡的值是一個(很接近)1.2 的估計值,但並非精確地等於 1.2。以一般的電腦" +"來說,他實際儲存的值是:\n" +"\n" +"::" #: ../../faq/design.rst:83 msgid "which is exactly::" msgstr "" +"而這個值正是:\n" +"\n" +"::" #: ../../faq/design.rst:87 msgid "" "The typical precision of 53 bits provides Python floats with 15--16 decimal " "digits of accuracy." -msgstr "" +msgstr "53 位元的精度讓 Python 可以有 15 至 16 小數位的準確度。" #: ../../faq/design.rst:90 msgid "" "For a fuller explanation, please see the :ref:`floating point arithmetic " "` chapter in the Python tutorial." msgstr "" +"要更完全的解釋可以查閱在 Python 教學的\\ :ref:`浮點運算 `\\ 一" +"章。" #: ../../faq/design.rst:95 msgid "Why are Python strings immutable?" -msgstr "為何Python字串為不可變動" +msgstr "為什麼 Python 字串不可變動?" #: ../../faq/design.rst:97 msgid "There are several advantages." @@ -161,6 +191,9 @@ msgid "" "unchanging. This is also one of the reasons for the distinction between " "tuples and lists." msgstr "" +"其一是效能:知道字串不可變動後,我們就可以在創造他的時候就分配好空間,而後他" +"的儲存空間需求就是固定不變的。這也是元組 (tuple) 和串列 (list) 相異的其中一" +"個原因。" #: ../../faq/design.rst:104 msgid "" @@ -169,16 +202,18 @@ msgid "" "and in Python, no amount of activity will change the string \"eight\" to " "anything else." msgstr "" +"另一個優點是在 Python 中,字串和數字一樣「基本」。沒有任何行為會把 8 這個數值" +"改成其他數值;同理,在 Python 中也沒有任何行為會修改字串「eight」。" #: ../../faq/design.rst:112 msgid "Why must 'self' be used explicitly in method definitions and calls?" -msgstr "" +msgstr "為何「self」在方法 (method) 定義和呼叫時一定要明確使用?" #: ../../faq/design.rst:114 msgid "" "The idea was borrowed from Modula-3. It turns out to be very useful, for a " "variety of reasons." -msgstr "此構想從Modula-3而來。有許多原因可以說是非常實用。" +msgstr "此構想從 Modula-3 而來。因為許多原因,他可以說是非常實用。" #: ../../faq/design.rst:117 msgid "" @@ -192,6 +227,12 @@ msgid "" "Some C++ and Java coding standards call for instance attributes to have an " "``m_`` prefix, so this explicitness is still useful in those languages, too." msgstr "" +"第一,這樣可以更明顯表現出你在用方法 (method) 或是實例 (instance) 的屬性,而" +"非一個區域變數。即使不知道類別 (class) 的定義,當看到 ``self.x`` 或 ``self." +"meth()``,就會很清楚地知道是正在使用實例的變數或是方法。在 C++ 裡,你可以藉由" +"沒有區域變數宣告來判斷這件事 ── 但在 Python 裡沒有區域變數宣告,所以你必須去" +"看類別的定義來確定。有些 C++ 和 Java 的程式碼規格要求要在實例屬性的名稱加上前" +"綴 ``m_``,所以這種明確性在那些語言也是很好用的。" #: ../../faq/design.rst:127 msgid "" @@ -204,6 +245,11 @@ msgid "" "class method wants to extend the base class method of the same name and thus " "has to call the base class method somehow." msgstr "" +"第二,當你想明確地使用或呼叫在某個類別裡的方法的時候,你不需要特殊的語法。在 " +"C++ 裡,如果你想用一個在繼承類別時被覆寫的基底類別方法,必須要用 ``::`` 運算" +"子 -- 但在 Python 裡,你可以直接寫成 ``baseclass.methodname(self, )``。這在 :meth:`__init__` 方法很好用,特別是在一個繼承的類別要擴充基底" +"類別的方法而要呼叫他時。" #: ../../faq/design.rst:136 msgid "" @@ -222,20 +268,31 @@ msgid "" "instance variables live in two different namespaces, and you need to tell " "Python which namespace to use." msgstr "" +"最後,他解決了關於實例變數指派的語法問題:因為區域變數在 Python 是(定義為)" +"在函式內被指派值的變數(且沒有被明確宣告成全域),所以會需要一個方法來告訴直" +"譯器這個指派運算是針對實例變數,而非針對區域變數,這在語法層面處理較好(為了" +"效率)。C++ 用宣告解決了這件事,但 Python 沒有,而為了這個原因而引入變數宣告" +"機制又略嫌浪費。但使用明確的 ``self.var`` 就可以把這個問題圓滿解決。同理,在" +"用實例變數的時候必須寫成 ``self.var`` 即代表對於在方法中不特定的名稱不需要去" +"看實例的內容。換句話說,區域變數和實例變數存在於兩個不同的命名空間 " +"(namespace),而你需要告訴 Python 要使用哪一個。" #: ../../faq/design.rst:154 msgid "Why can't I use an assignment in an expression?" -msgstr "" +msgstr "為何我不能在運算式 (expression) 中使用指派運算?" #: ../../faq/design.rst:156 msgid "Starting in Python 3.8, you can!" -msgstr "" +msgstr "從 Python 3.8 開始,你可以這麼做了!" #: ../../faq/design.rst:158 msgid "" "Assignment expressions using the walrus operator `:=` assign a variable in " "an expression::" msgstr "" +"指派運算式使用海象運算子 `:=` 來在運算式中指派變數值:\n" +"\n" +"::" #: ../../faq/design.rst:164 msgid "See :pep:`572` for more information." @@ -246,10 +303,12 @@ msgid "" "Why does Python use methods for some functionality (e.g. list.index()) but " "functions for other (e.g. len(list))?" msgstr "" +"為何 Python 對於一些功能實作使用方法(像是 list.index()),另一些使用函式(像" +"是 len(list))?" #: ../../faq/design.rst:171 msgid "As Guido said:" -msgstr "" +msgstr "如 Guido 所說:" #: ../../faq/design.rst:173 msgid "" @@ -259,6 +318,10 @@ msgid "" "problem. Compare the easy with which we rewrite a formula like x*(a+b) into " "x*a + x*b to the clumsiness of doing the same thing using a raw OO notation." msgstr "" +"(一) 對一些運算來說,前綴寫法看起來會比後綴寫法好 ── 前綴(和中綴!)運算在" +"數學上有更久遠的傳統,這些符號在視覺上幫助數學家們更容易思考問題。想想把 x*(a" +"+b) 這種式子展開成 x*a + x*b 的簡單,再比較一下古老的圈圈符號記法的笨拙就知道" +"了。" #: ../../faq/design.rst:180 msgid "" @@ -271,6 +334,11 @@ msgid "" "mapping has a get() or keys() method, or something that isn't a file has a " "write() method." msgstr "" +"(二) 當我看到一段程式碼寫著 len(x),我\\ *知道*\\ 他要找某個東西的長度。這" +"告訴了我兩件事:結果是一個整數、參數是某種容器。相對地,當我看到 x.len(),我" +"必須先知道 x 是某種容器,並實作了一個介面或是繼承了一個有標準 len() 的類別。" +"遇到一個沒有實作映射 (mapping) 的類別卻有 get() 或 keys() 方法,或是不是檔案" +"但卻有 write() 方法時,我們偶爾會覺得困惑。" #: ../../faq/design.rst:189 msgid "https://mail.python.org/pipermail/python-3000/2006-November/004643.html" @@ -279,7 +347,7 @@ msgstr "" #: ../../faq/design.rst:193 msgid "Why is join() a string method instead of a list or tuple method?" -msgstr "" +msgstr "為何 join() 是字串方法而非串列 (list) 或元組 (tuple) 方法?" #: ../../faq/design.rst:195 msgid "" @@ -289,14 +357,22 @@ msgid "" "methods have been widely accepted, but the one which appears to make some " "programmers feel uncomfortable is::" msgstr "" +"自 Python 1.6 之後,字串變得很像其他標準的型別,也在此時,一些可以和字串模組" +"的函式有相同功能的方法也被加入。大多數的新方法都被廣泛接受,但有一個方法似乎" +"讓一些程式人員不舒服:\n" +"\n" +"::" #: ../../faq/design.rst:203 msgid "which gives the result::" msgstr "" +"結果是:\n" +"\n" +"::" #: ../../faq/design.rst:207 msgid "There are two common arguments against this usage." -msgstr "" +msgstr "通常有兩個反對這個用法的論點。" #: ../../faq/design.rst:209 msgid "" @@ -306,6 +382,9 @@ msgid "" "on names bound to strings there is no logical reason to make them " "unavailable on literals." msgstr "" +"第一項這麼說:「用字串文本 (string literal) (字串常數)看起來真的很醜」,也許真的" +"如此,但字串文本就只是一個固定值。如果方法可以用在值為字串的變數上," +"那沒道理字串文本不能被使用。" #: ../../faq/design.rst:215 msgid "" @@ -314,12 +393,19 @@ msgid "" "For some reason there seems to be much less difficulty with having :meth:" "`~str.split` as a string method, since in that case it is easy to see that ::" msgstr "" +"第二個反對意見通常是:「我是在叫一個序列把它的成員用一個字串常數連接起來」。" +"但很遺憾地,你並不是在這樣做。因為某種原因,把 :meth:`~str.split` 當成字串方" +"法比較簡單,因為這樣我們可以輕易地看到:\n" +"\n" +"::" #: ../../faq/design.rst:222 msgid "" "is an instruction to a string literal to return the substrings delimited by " "the given separator (or, by default, arbitrary runs of white space)." msgstr "" +"這是在叫一個字串文本回傳由指定的分隔符號(或是預設為空白)分出的子字串的指" +"令。" #: ../../faq/design.rst:225 msgid "" @@ -329,10 +415,13 @@ msgid "" "obeys the rules for sequence objects, including any new classes you might " "define yourself. Similar methods exist for bytes and bytearray objects." msgstr "" +":meth:`~str.join` 是一個字串方法,因為在用他的時候,你是告訴分隔字串去走遍整" +"個字串序列,並將自己插入到相鄰的兩項之間。這個方法的參數可以是任何符合序列規" +"則的物件,包括自定義的新類別。在 bytes 和 bytearray 物件也有類似的方法可用。" #: ../../faq/design.rst:233 msgid "How fast are exceptions?" -msgstr "" +msgstr "例外處理有多快?" #: ../../faq/design.rst:235 msgid "" @@ -340,12 +429,20 @@ msgid "" "Actually catching an exception is expensive. In versions of Python prior to " "2.0 it was common to use this idiom::" msgstr "" +"如果沒有例外被丟出,一個 try/except 區塊是非常有效率的。事實上,抓捕例外要付" +"出昂貴的代價。在 Python 2.0 以前,這樣使用是相當常見的:\n" +"\n" +"::" #: ../../faq/design.rst:245 msgid "" "This only made sense when you expected the dict to have the key almost all " "the time. If that wasn't the case, you coded it like this::" msgstr "" +"這只有在你預料這個字典大多數時候都有鍵的時候才合理。如果並非如此,你應該寫" +"成:\n" +"\n" +"::" #: ../../faq/design.rst:253 msgid "" @@ -353,10 +450,13 @@ msgid "" "getvalue(key))``, but only if the ``getvalue()`` call is cheap enough " "because it is evaluated in all cases." msgstr "" +"單就這個情況來說,你也可以用 ``value = dict.setdefault(key, " +"getvalue(key))``,不過只有在 ``getvalue()`` 代價不大的時候才能用,畢竟他每次" +"都會被執行。" #: ../../faq/design.rst:259 msgid "Why isn't there a switch or case statement in Python?" -msgstr "" +msgstr "為什麼 Python 內沒有 switch 或 case 陳述式?" #: ../../faq/design.rst:261 msgid "" @@ -364,6 +464,8 @@ msgid "" "else``. For literal values, or constants within a namespace, you can also " "use a ``match ... case`` statement." msgstr "" +"你可以用一連串的 ``if... elif... elif... else`` 來輕易達成相同的效果。對於單" +"純的值或是在命名空間內的常數,你也可以使用 ``match ... case`` 陳述式。" #: ../../faq/design.rst:265 msgid "" @@ -371,12 +473,19 @@ msgid "" "possibilities, you can create a dictionary mapping case values to functions " "to call. For example::" msgstr "" +"如果可能性很多,你可以用字典去映射要呼叫的函式。舉例來說:\n" +"\n" +"::" #: ../../faq/design.rst:276 msgid "" "For calling methods on objects, you can simplify yet further by using the :" "func:`getattr` built-in to retrieve methods with a particular name::" msgstr "" +"對於呼叫物件裡的方法,你可以利用內建用來找尋特定方法的函式 :func:`getattr` 來" +"做進一步的簡化:\n" +"\n" +"::" #: ../../faq/design.rst:288 msgid "" @@ -385,12 +494,14 @@ msgid "" "from an untrusted source, an attacker would be able to call any method on " "your object." msgstr "" +"我們建議在方法名稱加上前綴,以這個例子來說是 像是 ``visit_``。沒有前綴的話," +"一旦收到從不信任來源的值,攻擊者便可以隨意呼叫在你的專案內的方法。" #: ../../faq/design.rst:294 msgid "" "Can't you emulate threads in the interpreter instead of relying on an OS-" "specific thread implementation?" -msgstr "" +msgstr "為何不能在直譯器上模擬執行緒,而要使用作業系統的特定實作方式?" #: ../../faq/design.rst:296 msgid "" @@ -399,6 +510,9 @@ msgid "" "almost random moments. Therefore, a complete threads implementation " "requires thread support for C." msgstr "" +"答案一:很不幸地,直譯器對每個 Python 的堆疊框 (stack frame) 會推至少一個 C " +"的堆疊框。同時,擴充套件可以隨時呼叫 Python,因此完整的實作必須要支援 C 的執" +"行緒。" #: ../../faq/design.rst:301 msgid "" @@ -406,10 +520,12 @@ msgid "" "stackless-dev/stackless/wiki>`_, which has a completely redesigned " "interpreter loop that avoids the C stack." msgstr "" +"答案二:幸運地,`無堆疊 (Stackless) Python `_ 完全重新設計了直譯器迴圈,並避免了 C 堆疊。" #: ../../faq/design.rst:306 msgid "Why can't lambda expressions contain statements?" -msgstr "為何lambda表示式不能包含在敘述內" +msgstr "為何 lambda 運算式不能包含陳述式?" #: ../../faq/design.rst:308 msgid "" @@ -419,6 +535,10 @@ msgid "" "other languages, where they add functionality, Python lambdas are only a " "shorthand notation if you're too lazy to define a function." msgstr "" +"Python 的 lambda 運算式不能包含陳述式是因為 Python 的語法框架無法處理包在運算" +"式中的陳述式。然而,在 Python 裡這並不是一個嚴重的問題。不像在其他語言中有獨" +"立功能的 lambda,Python 的 lambda 只是一個在你懶得定義函式時可用的一個簡寫表" +"達法。" #: ../../faq/design.rst:314 msgid "" @@ -429,22 +549,28 @@ msgid "" "(which is exactly the same type of object that a lambda expression yields) " "is assigned!" msgstr "" +"函式已經是 Python 裡的一級物件 (first class objects),而且可以在區域範圍內被" +"宣告。因此唯一用 lambda 而非區域性的函式的優點就是你不需要多想一個函式名稱 — " +"但這樣就會是一個區域變數被指定成函式物件(和 lambda 運算式的結果同類)!" #: ../../faq/design.rst:322 msgid "Can Python be compiled to machine code, C or some other language?" -msgstr "Python可以被編譯成機器語言或C語言或其他種語言嗎?" +msgstr "Python 可以被編譯成機器語言、C 語言或其他種語言嗎?" #: ../../faq/design.rst:324 msgid "" -"`Cython `_ compiles a modified version of Python with " -"optional annotations into C extensions. `Nuitka `_ " +"`Cython `_ compiles a modified version of Python with " +"optional annotations into C extensions. `Nuitka `_ " "is an up-and-coming compiler of Python into C++ code, aiming to support the " "full Python language." msgstr "" +"`Cython `_ 可以編譯一個調整過有選擇性註解的 Python 版" +"本。 `Nuitka `_ 是一個有潛力編譯器,可以把 Python 編" +"譯成 C++,他的目標是支援完整的 Python 語言。" #: ../../faq/design.rst:331 msgid "How does Python manage memory?" -msgstr "Python如何管理記憶體?" +msgstr "Python 如何管理記憶體?" #: ../../faq/design.rst:333 msgid "" @@ -456,21 +582,34 @@ msgid "" "provides functions to perform a garbage collection, obtain debugging " "statistics, and tune the collector's parameters." msgstr "" +"Python 記憶體管理的細節取決於實作。Python 的標準實作 :term:`CPython` 使用參照" +"計次 (reference counting) 來偵測不再被存取的物件,並用另一個機制來收集參照循" +"環 (reference cycle)、定期執行循環偵測演算法來找不再使用的循環並刪除相關物" +"件。 :mod:`gc` 模組提供了可以執行垃圾收集、抓取除錯統計數據和調整收集器參數的" +"函式。" #: ../../faq/design.rst:341 msgid "" -"Other implementations (such as `Jython `_ or `PyPy " -"`_), however, can rely on a different mechanism such as " +"Other implementations (such as `Jython `_ or `PyPy " +"`_), however, can rely on a different mechanism such as " "a full-blown garbage collector. This difference can cause some subtle " "porting problems if your Python code depends on the behavior of the " "reference counting implementation." msgstr "" +"然而,在其他實作(像是 `Jython `_ 或 `PyPy `_)中,會使用像是成熟的垃圾收集器等不同機制。如果你的 Python 程" +"式碼的表現取決於參照計次的實作,這個相異處會導致一些微" +"小的移植問題。" #: ../../faq/design.rst:347 msgid "" "In some Python implementations, the following code (which is fine in " "CPython) will probably run out of file descriptors::" msgstr "" +"在一些 Python 實作中,下面這段程式碼(在 CPython 可以正常運作)可能會把檔案描" +"述子 (file descriptor) 用盡:\n" +"\n" +"::" #: ../../faq/design.rst:354 msgid "" @@ -479,6 +618,9 @@ msgid "" "those file objects will only get collected (and closed) at varying and " "possibly long intervals." msgstr "" +"實際上,使用 CPython 的參照計次和解構方案 (destructor " +"scheme),每個對\\ *f*\\ 的新指派都會關閉前面打開的檔案。然而用傳統的垃圾回收 " +"(GC) 的話,這些檔案物件只會在不固定且有可能很長的時間後被收集(並關閉)。" #: ../../faq/design.rst:359 msgid "" @@ -486,10 +628,15 @@ msgid "" "should explicitly close the file or use the :keyword:`with` statement; this " "will work regardless of memory management scheme::" msgstr "" +"如果你希望你的程式碼在任何 Python 實作版本中都可以運作,那你應該清楚地關閉檔" +"案或是使用 :keyword:`with` 陳述式,如此一來,不用管記憶體管理的方法,他也會正" +"常運作:\n" +"\n" +"::" #: ../../faq/design.rst:369 msgid "Why doesn't CPython use a more traditional garbage collection scheme?" -msgstr "為何CPython不使用更多傳統的垃圾回收機制?" +msgstr "為何 CPython 不使用更多傳統的垃圾回收機制?" #: ../../faq/design.rst:371 msgid "" @@ -499,6 +646,9 @@ msgid "" "transparent, it isn't completely transparent; patches are required to get " "Python to work with it.)" msgstr "" +"第一,這並不是 C 的標準功能,因此他的可攜性低。(對,我們知道 Boehm GC 函式" +"庫。他有可相容於\\ *大多數*\\ 平台的組合語言程式碼,但依然不是全部,而即便它" +"大多數是通透的,也並不完全,要讓它跟 Python 相容還是需要做一些修補。)" #: ../../faq/design.rst:377 msgid "" @@ -509,10 +659,15 @@ msgid "" "malloc() and free(), and may not want Python's. Right now, CPython works " "with anything that implements malloc() and free() properly." msgstr "" +"傳統的垃圾收集 (GC) 在 Python 被嵌入其他應用程式時也成了一個問題。在獨立的 " +"Python 程式裡當然可以把標準的 malloc() 和 free() 換成 GC 函式庫提供的其他版" +"本;但一個嵌著 Python 的應用程式可能想用\\ *自己*\\ 的 malloc() 和 free() 替" +"代品,而不是用 Python 的。以現在來說,CPython 和實作 malloc() 和 free() 的程" +"式相處融洽。" #: ../../faq/design.rst:386 msgid "Why isn't all memory freed when CPython exits?" -msgstr "當CPython結束時,為何所有的記憶體不會被釋放?" +msgstr "當 CPython 結束時,為何所有的記憶體不會被釋放?" #: ../../faq/design.rst:388 msgid "" @@ -523,16 +678,22 @@ msgid "" "about these). Python is, however, aggressive about cleaning up memory on " "exit and does try to destroy every single object." msgstr "" +"當離開 Python 時,從 Python 模組的全域命名空間來的物件並非總是會被釋放。在有" +"循環引用的時候,這可能會發生。有些記憶體是被 C 函式庫取用的,他們不可能被釋放" +"(例如:像是 Purify 之類的工具會抱怨)。然而,Python 在關閉的時候會積極清理記" +"憶體並嘗試刪除每個物件。" #: ../../faq/design.rst:395 msgid "" "If you want to force Python to delete certain things on deallocation use " "the :mod:`atexit` module to run a function that will force those deletions." msgstr "" +"如果你想要強迫 Python 在釋放記憶體時刪除特定的東西,你可以用 :mod:`atexit` 模" +"組來執行會強制刪除的函式。" #: ../../faq/design.rst:400 msgid "Why are there separate tuple and list data types?" -msgstr "" +msgstr "為何要把元組 (tuple) 和串列 (list) 分成兩個資料型態?" #: ../../faq/design.rst:402 msgid "" @@ -543,6 +704,10 @@ msgid "" "Cartesian coordinate is appropriately represented as a tuple of two or three " "numbers." msgstr "" +"串列和元組在很多方面相當相似,但通常用在完全不同的地方。元組可以想成 Pascal " +"的紀錄 (record) 或是 C 的結構 (struct),是一小群相關聯但可能是不同型別的資" +"料集合,以一組為單位進行操作。舉例來說,一個笛卡兒坐標系可以適當地表示成一個" +"有二或三個值的元組。" #: ../../faq/design.rst:409 msgid "" @@ -553,6 +718,9 @@ msgid "" "Functions which operate on this output would generally not break if you " "added another file or two to the directory." msgstr "" +"另一方面,串列更像是其他語言的陣列 (array)。他可以有不固定個同類別物件,且為" +"逐項操作。舉例來說,``os.listdir('.')`` 回傳當下目錄裡的檔案,以包含字串的串" +"列表示。如果你新增了幾個檔案到這個目錄,一般來說操作結果的函式也會正常運作。" #: ../../faq/design.rst:416 msgid "" @@ -562,10 +730,13 @@ msgid "" "be used as dictionary keys, and hence only tuples and not lists can be used " "as keys." msgstr "" +"元組則是不可變的,代表一旦元組被建立,你就不能夠改變裡面的任何一個值。而串列" +"可變,所以你可以改變裡面的元素。只有不可變的元素可以成為字典的鍵,所以只能把" +"元組當成鍵,而串列則不行。" #: ../../faq/design.rst:423 msgid "How are lists implemented in CPython?" -msgstr "串列 (lists) 在 CPython 中是怎麼實作的?" +msgstr "串列 (list) 在 CPython 中是怎麼實作的?" #: ../../faq/design.rst:425 msgid "" @@ -574,12 +745,15 @@ msgid "" "objects, and keeps a pointer to this array and the array's length in a list " "head structure." msgstr "" +"CPython 的串列 (list) 事實上是可變長度的陣列 (array),而不是像 Lisp 語言的鏈" +"接串列 (linked list)。實作上,他是一個連續的物件參照 (reference) 陣列,並把" +"指向此陣列的指標 (pointer) 和陣列長度存在串列的標頭結構內。" #: ../../faq/design.rst:429 msgid "" "This makes indexing a list ``a[i]`` an operation whose cost is independent " "of the size of the list or the value of the index." -msgstr "" +msgstr "因此,用索引來找串列特定項 ``a[i]`` 的代價和串列大小或是索引值無關。" #: ../../faq/design.rst:432 msgid "" @@ -588,6 +762,9 @@ msgid "" "repeatedly; when the array must be grown, some extra space is allocated so " "the next few times don't require an actual resize." msgstr "" +"當新物件被新增或插入時,陣列會被調整大小。為了改善多次加入物件的效率,我們有" +"用一些巧妙的方法,當陣列必須變大時,會多收集一些額外的空間,接下來幾次新增時" +"就不需要再調整大小了。" #: ../../faq/design.rst:439 msgid "How are dictionaries implemented in CPython?" @@ -600,6 +777,8 @@ msgid "" "operation by far) under most circumstances, and the implementation is " "simpler." msgstr "" +"CPython 的字典是用可調整大小的雜湊表 (hash table) 實作的。比起 B 樹 (B-" +"tree),在搜尋(目前為止最常見的操作)方面有更好的表現,實作上也較為簡單。" #: ../../faq/design.rst:445 msgid "" @@ -613,10 +792,15 @@ msgid "" "dictionaries take constant time -- O(1), in Big-O notation -- to retrieve a " "key." msgstr "" +"字典利用內建 :func:`hash` 函式,對每個鍵做雜湊計算。雜湊結果依據鍵的值和個別" +"執行緒 (processes) 的種子而有相當大的差距。例如,\"Python\" 的雜湊是 " +"-539294296,而只差一個字的 \"python\" 則是 1142331976。雜湊結果接著被用來計算值" +"在內部陣列儲存的位置。假設你存的鍵都有不同的雜湊值,那字典只需要常數時間 — 用" +"大 O 表示法 (Big-O notation) 就是 O(1) — 來找任意一個鍵。" #: ../../faq/design.rst:456 msgid "Why must dictionary keys be immutable?" -msgstr "" +msgstr "為何字典的鍵一定是不可變的?" #: ../../faq/design.rst:458 msgid "" @@ -630,6 +814,11 @@ msgid "" "be found either, because the value of the object found in that hash bin " "would be different." msgstr "" +"實作字典用的雜湊表是根據鍵的值做計算從而找到鍵的。如果鍵可變的話,他的值就可" +"以改變,則雜湊的結果也會一起變動。但改變鍵的物件的人無從得知他被用來當成字典" +"的鍵,所以無法修改字典的內容。然後,當你嘗試在字典中尋找這個物件時,因為雜湊" +"值不同的緣故,你找不到他。而如果你嘗試用舊的值去尋找,也一樣找不到,因為他的" +"雜湊結果和原先物件不同。" #: ../../faq/design.rst:467 msgid "" @@ -638,16 +827,22 @@ msgid "" "as the list ``L``. Tuples are immutable and can therefore be used as " "dictionary keys." msgstr "" +"如果你想要用串列作為字典的索引,把他轉換成元組即可。``tuple(L)`` 函式會建立一" +"個和串列 ``L`` 一樣內容的元組。而元組是不可變的,所以可以用來當成字典的鍵。" #: ../../faq/design.rst:471 msgid "Some unacceptable solutions that have been proposed:" -msgstr "" +msgstr "也有人提出一些不能接受的方法:" #: ../../faq/design.rst:473 msgid "" "Hash lists by their address (object ID). This doesn't work because if you " "construct a new list with the same value it won't be found; e.g.::" msgstr "" +"用串列的記憶體位址(物件 id)來雜湊。這不會成功,因為你如果用同樣的值建立一個" +"新的串列,是找不到的。舉例來說:\n" +"\n" +"::" #: ../../faq/design.rst:479 msgid "" @@ -656,6 +851,8 @@ msgid "" "words, dictionary keys should be compared using ``==``, not using :keyword:" "`is`." msgstr "" +"這將會導致 :exc:`KeyError` 例外,因為 ``[1, 2]`` 的 id 在第一行和第二行是不同" +"的。換句話說,字典的鍵應該要用 ``==`` 來做比較,而不是用 :keyword:`is`。" #: ../../faq/design.rst:483 msgid "" @@ -663,6 +860,8 @@ msgid "" "being a mutable object, could contain a reference to itself, and then the " "copying code would run into an infinite loop." msgstr "" +"複製一個串列作為鍵。這一樣不會成功,因為串列是可變的,他可以包含自己的參照," +"所以複製會形成一個無窮迴圈。" #: ../../faq/design.rst:487 msgid "" @@ -671,6 +870,9 @@ msgid "" "by accident. It also invalidates an important invariant of dictionaries: " "every value in ``d.keys()`` is usable as a key of the dictionary." msgstr "" +"允許串列作為鍵,但告訴使用者不要更動他。當你不小心忘記或是更動了這個串列,會" +"產生一種難以追蹤的 bug。他同時也違背了一項字典的重要定則:在 ``d.keys()`` 的" +"每個值都可以當成字典的鍵。" #: ../../faq/design.rst:492 msgid "" @@ -681,6 +883,9 @@ msgid "" "read-only -- and again, self-referential objects could cause an infinite " "loop." msgstr "" +"一旦串列被當成鍵,把他標記成只能讀取。問題是,這不只要避免最上層的物件改變" +"值,就像用元組包含串列來做為鍵。把一個物件當成鍵,需要將從他開始可以接觸到的" +"所有物件都標記成只能讀取 — 所以再一次,自己參照自己的物件會導致無窮迴圈。" #: ../../faq/design.rst:498 msgid "" @@ -691,6 +896,12 @@ msgid "" "dictionary (or other hash based structure), remain fixed while the object is " "in the dictionary (or other structure). ::" msgstr "" +"如果你需要的話,這裡有個小技巧可以幫你,但請自己承擔風險:你可以把一個可變物" +"件包裝進一個有 :meth:`__eq__` 和 :meth:`__hash__` 方法的類別。只要這種包裝物" +"件還存在於字典(或其他類似結構)中,你就必須確定在字典(或其他用雜湊為基底的" +"結構)中他們的雜湊值會保持恆定。\n" +"\n" +"::" #: ../../faq/design.rst:522 msgid "" @@ -698,6 +909,8 @@ msgid "" "members of the list may be unhashable and also by the possibility of " "arithmetic overflow." msgstr "" +"請注意,雜湊的計算可能變得複雜,因為有串列成員不可雜湊 (unhashable) 和算術溢" +"位的可能性。" #: ../../faq/design.rst:526 msgid "" @@ -707,6 +920,10 @@ msgid "" "not. If you fail to meet these restrictions dictionaries and other hash " "based structures will misbehave." msgstr "" +"此外,不管物件是否在字典中,如果 ``o1 == o2``\\ (即 ``o1.__eq__(o2) is " +"True``),則 ``hash(o1) == hash(o2)``\\ (即 ``o1.__hash__() == o2." +"__hash__()``),這個事實必須要成立。如果無法滿足這項限制,那字典和其他用雜湊" +"為基底的結構會出現不正常的行為。" #: ../../faq/design.rst:531 msgid "" @@ -715,10 +932,13 @@ msgid "" "you are prepared to think hard about the requirements and the consequences " "of not meeting them correctly. Consider yourself warned." msgstr "" +"至於 ListWrapper,只要這個包裝過的物件在字典中,裡面的串列就不能改變以避免不" +"正常的事情發生。除非你已經謹慎思考過你的需求和無法滿足條件的後果,不然請不要" +"這麼做。請自行注意。" #: ../../faq/design.rst:538 msgid "Why doesn't list.sort() return the sorted list?" -msgstr "為何list.sort()不是回傳排序過的串列?" +msgstr "為何 list.sort() 不是回傳排序過的串列?" #: ../../faq/design.rst:540 msgid "" @@ -729,6 +949,9 @@ msgid "" "when you need a sorted copy but also need to keep the unsorted version " "around." msgstr "" +"在重視效能的情況下,把串列複製一份有些浪費。因此,:meth:`list.sort` 直接在串" +"列裡做排序。為了提醒你這件事,他不會回傳排序過的串列。這樣一來,當你需要排序" +"過和未排序過的串列時,你就不會被誤導而不小心覆蓋掉串列。" #: ../../faq/design.rst:546 msgid "" @@ -737,10 +960,15 @@ msgid "" "it and returns it. For example, here's how to iterate over the keys of a " "dictionary in sorted order::" msgstr "" +"如果你想要他回傳新的串列,那可以改用內建的 :func:`sorted`。他會用提供的可疊代" +"物件 (iterable) 來排序建立新串列,並回傳之。例如,以下這個範例會說明如何有序" +"地疊代字典的鍵:\n" +"\n" +"::" #: ../../faq/design.rst:556 msgid "How do you specify and enforce an interface spec in Python?" -msgstr "" +msgstr "如何在 Python 中指定和強制使用一個介面規範 (interface spec)?" #: ../../faq/design.rst:558 msgid "" @@ -749,6 +977,8 @@ msgid "" "module. Many feel that compile-time enforcement of interface specifications " "helps in the construction of large programs." msgstr "" +"像是 C++ 和 Java 等語言提供了模組的介面規範,他描述了該模組的方法和函式的原" +"型。很多人認為這種在編譯時強制執行的介面規範在建構大型程式時十分有幫助。" #: ../../faq/design.rst:563 msgid "" @@ -759,12 +989,18 @@ msgid "" "`~collections.abc.Iterable`, :class:`~collections.abc.Container`, and :class:" "`~collections.abc.MutableMapping`." msgstr "" +"Python 2.6 加入了 :mod:`abc` 模組,讓你可以定義抽象基底類別 (Abstract Base " +"Class, ABC)。你可以使用 :func:`isinstance` 和 :func:`issubclass` 來確認一" +"個實例或是類別是否實作了某個抽象基底類別。而 :mod:`collections." +"abc` 模組定義了一系列好用的抽象基底類別,像是 :class:`~collections.abc." +"Iterable`、:class:`~collections.abc.Container` 和 :class:`~collections.abc." +"MutableMapping`。" #: ../../faq/design.rst:570 msgid "" "For Python, many of the advantages of interface specifications can be " "obtained by an appropriate test discipline for components." -msgstr "" +msgstr "對 Python 來說,很多介面規範的優點可以用對元件適當的測試規則來達到。" #: ../../faq/design.rst:573 msgid "" @@ -777,6 +1013,11 @@ msgid "" "be used to construct exhaustive test suites that exercise every line of code " "in a module." msgstr "" +"一個針對模組的好測試套件提供了回歸測試 (regression testing),並作為模組介面規" +"範和一組範例。許多 Python 模組可以直接當成腳本執行,並提供簡單的「自我測" +"試」。即便模組使用了複雜的外部介面,他依然可以用外部介面的簡單的「樁」(stub) " +"模擬來獨立測試。:mod:`doctest` 和 :mod:`unittest` 模組或第三方的測試框架可以" +"用來建構詳盡徹底的測試套件來測試模組裡的每一行程式碼。" #: ../../faq/design.rst:581 msgid "" @@ -788,6 +1029,11 @@ msgid "" "test that your :meth:`append` implementation will actually do this " "correctly, but it's trivial to check this property in a test suite." msgstr "" +"就像介面規範一樣,一個適當的測試規則在建造大型又複雜的 Python 應用程式時可以" +"幫上忙。事實上,他可能可以有更好的表現,因為介面規範無法測試程式的特定屬性。" +"舉例來說,:meth:`append` 方法應該要在某個內部的串列最後面加上新的元素,而介面" +"規範沒辦法測試你的 :meth:`append` 是不是真的有正確的實作,但這在測試套件裡是" +"件很簡單的事。" #: ../../faq/design.rst:589 msgid "" @@ -797,10 +1043,13 @@ msgid "" "write any of the actual code. Of course Python allows you to be sloppy and " "not write test cases at all." msgstr "" +"撰寫測試套件相當有幫助,而你會像要把程式碼設計成好測試的樣子。測試驅動開發 " +"(test-driven development) 是一個越來越受歡迎的設計方法,他要求先完成部分的測" +"試套件,再去撰寫真的要用的程式碼。當然 Python 也允許你草率地不寫任何測試。" #: ../../faq/design.rst:597 msgid "Why is there no goto?" -msgstr "為何沒有goto語法?" +msgstr "為何沒有 goto 語法?" #: ../../faq/design.rst:599 msgid "" @@ -811,6 +1060,11 @@ msgid "" "expressions) and loop (with ``while`` and ``for`` statements, possibly " "containing ``continue`` and ``break``)." msgstr "" +"在 1970 年代,人們了解到沒有限制的 goto 會導致混亂、難以理解和修改的「義大利" +"麵」程式碼 (\"spaghetti\" code)。在高階語言裡,這也是不需要的,因為有方法可以" +"做邏輯分支(以 Python 來說,用 ``if`` 陳述式和 ``or``、``and`` 及 ``if-" +"else`` 運算式)和迴圈(用 ``while`` 和 ``for`` 陳述式,可能會有 ``continue`` " +"和 ``break``)。" #: ../../faq/design.rst:606 msgid "" @@ -819,16 +1073,21 @@ msgid "" "all reasonable uses of the \"go\" or \"goto\" constructs of C, Fortran, and " "other languages. For example::" msgstr "" +"我們也可以用例外來做「結構化的 goto」,這甚至可以跨函式呼叫。很多人覺得例外可" +"以方便地模擬在 C、Fortran 和其他語言裡各種合理使用的「go」和「goto」。例" +"如:\n" +"\n" +"::" #: ../../faq/design.rst:622 msgid "" "This doesn't allow you to jump into the middle of a loop, but that's usually " "considered an abuse of goto anyway. Use sparingly." -msgstr "" +msgstr "這依然不能讓你跳進迴圈內,這通常被認為是對 goto 的濫用。請小心使用。" #: ../../faq/design.rst:627 msgid "Why can't raw strings (r-strings) end with a backslash?" -msgstr "" +msgstr "為何純字串 (r-string) 不能以反斜線結尾?" #: ../../faq/design.rst:629 msgid "" @@ -836,6 +1095,8 @@ msgid "" "unpaired backslash at the end escapes the closing quote character, leaving " "an unterminated string." msgstr "" +"更精確地來說,他不能以奇數個反斜線結尾:尾端未配對的反斜線會使結尾的引號被轉" +"義 (escapes),變成一個未結束的字串。" #: ../../faq/design.rst:633 msgid "" @@ -846,21 +1107,31 @@ msgid "" "pass on the string quote character by escaping it with a backslash. These " "rules work well when r-strings are used for their intended purpose." msgstr "" +"設計出純字串是為了提供有自己反斜線轉義處理的處理器(主要是正規表示式)一個方" +"便的輸入方式。這種處理器會把未配對的結尾反斜線當成錯誤,所以純字串不允許如" +"此。相對地,他讓你用一個反斜線轉義引號。這些規則在他們預想的目的上正常地運" +"作。" #: ../../faq/design.rst:640 msgid "" "If you're trying to build Windows pathnames, note that all Windows system " "calls accept forward slashes too::" msgstr "" +"如果你嘗試建立 Windows 的路徑名稱,請注意 Windows 系統指令也接受一般斜線:\n" +"\n" +"::" #: ../../faq/design.rst:645 msgid "" "If you're trying to build a pathname for a DOS command, try e.g. one of ::" msgstr "" +"如果你嘗試建立 DOS 指令的路徑名稱,試試看使用以下的範例:\n" +"\n" +"::" #: ../../faq/design.rst:653 msgid "Why doesn't Python have a \"with\" statement for attribute assignments?" -msgstr "" +msgstr "為何 Python 沒有屬性賦值的 with 陳述式?" #: ../../faq/design.rst:655 msgid "" @@ -868,10 +1139,14 @@ msgid "" "code on the entrance and exit from the block. Some languages have a " "construct that looks like this::" msgstr "" +"Python 的 with 陳述式包裝了一區塊程式的執行,在進入和離開該區塊時執行程式碼。" +"一些語言會有像如下的結構:\n" +"\n" +"::" #: ../../faq/design.rst:663 msgid "In Python, such a construct would be ambiguous." -msgstr "" +msgstr "但在 Python,這種結構是模糊的。" #: ../../faq/design.rst:665 msgid "" @@ -880,6 +1155,9 @@ msgid "" "assigned to. This is the main point of static typing -- the compiler " "*always* knows the scope of every variable at compile time." msgstr "" +"在其他語言裡,像是 Object Pascal、Delphi 和 C++,使用的是靜態型別,所以我們可" +"以清楚地知道是哪一個成員被指派值。這是靜態型別的重點 — 在編譯的時候,編譯器" +"\\ *永遠*\\ 都知道每個變數的作用域 (scope)。" #: ../../faq/design.rst:670 msgid "" @@ -889,10 +1167,16 @@ msgid "" "simple reading, what attribute is being referenced: a local one, a global " "one, or a member attribute?" msgstr "" +"Python 使用的是動態型別。所以我們不可能提前知道在執行時哪個屬性會被使用到。成" +"員屬性可能在執行時從物件中被新增或移除。這使得如果簡單來看的話,我們無法得知" +"以下哪個屬性會被使用:區域的、全域的、或是成員屬性?" #: ../../faq/design.rst:676 msgid "For instance, take the following incomplete snippet::" msgstr "" +"以下列不完整的程式碼為例:\n" +"\n" +"::" #: ../../faq/design.rst:682 msgid "" @@ -902,6 +1186,10 @@ msgid "" "variable named \"x\", will it be used inside the with block? As you see, " "the dynamic nature of Python makes such choices much harder." msgstr "" +"這段程式碼假設「a」有一個叫做「x」的成員屬性。然後,Python 裡並沒有任何跡象告" +"訴直譯器這件事。在假設「a」是一個整數的話,那會發生什麼事?如果有一個全域變數" +"稱為「x」,那在這個 with 區塊會被使用嗎?如你所見,Python 動態的天性使得這種" +"選擇更加困難。" #: ../../faq/design.rst:688 msgid "" @@ -909,10 +1197,17 @@ msgid "" "code volume) can, however, easily be achieved in Python by assignment. " "Instead of::" msgstr "" +"然而,with 陳述式或類似的語言特性(減少程式碼量)的主要好處可以透過賦值來達" +"成。相較於這樣寫:\n" +"\n" +"::" #: ../../faq/design.rst:695 msgid "write this::" msgstr "" +"應該寫成這樣:\n" +"\n" +"::" #: ../../faq/design.rst:702 msgid "" @@ -920,10 +1215,12 @@ msgid "" "bindings are resolved at run-time in Python, and the second version only " "needs to perform the resolution once." msgstr "" +"這也有提升執行速度的副作用,因為 Python 的名稱綁定解析會在執行的時候發生,而" +"第二版只需要執行解析一次即可。" #: ../../faq/design.rst:708 msgid "Why don't generators support the with statement?" -msgstr "" +msgstr "為何產生器 (generator) 不支援 with 陳述式?" #: ../../faq/design.rst:710 msgid "" @@ -932,20 +1229,29 @@ msgid "" "iterator run to completion, no closing is needed. When it is, wrap it as " "\"contextlib.closing(generator)\" in the 'with' statement." msgstr "" +"出於技術原因,把產生器直接用作情境 (context) 管理器會無法正常運作。因為通常" +"來說,產生器是被當成疊代器 (iterator),到最後完成時不需要被手動關閉。但如果你" +"需要的話,你可以在 with 陳述式裡用「contextlib.closing(generator)」來包裝他。" #: ../../faq/design.rst:717 msgid "Why are colons required for the if/while/def/class statements?" -msgstr "" +msgstr "為何 if、while、def、class 陳述式裡需要冒號?" #: ../../faq/design.rst:719 msgid "" "The colon is required primarily to enhance readability (one of the results " "of the experimental ABC language). Consider this::" msgstr "" +"需要冒號主要是為了增加可讀性(由 ABC 語言的實驗得知)。試想如下範例:\n" +"\n" +"::" #: ../../faq/design.rst:725 msgid "versus ::" msgstr "" +"以及:\n" +"\n" +"::" #: ../../faq/design.rst:730 msgid "" @@ -953,6 +1259,8 @@ msgid "" "colon sets off the example in this FAQ answer; it's a standard usage in " "English." msgstr "" +"注意第二個例子稍微易讀一些的原因。可以更進一步觀察,一個冒號是如何放在這個 " +"FAQ 答案的例子裡的,這是標準的英文用法。" #: ../../faq/design.rst:733 msgid "" @@ -961,16 +1269,21 @@ msgid "" "needs to be increased instead of having to do a more elaborate parsing of " "the program text." msgstr "" +"另一個小原因是冒號會使編輯器更容易做語法突顯,他們只需要看冒號的位置就可以決" +"定是否需要更多縮排,而不用做更多繁複精密的程式碼剖析。" #: ../../faq/design.rst:739 msgid "Why does Python allow commas at the end of lists and tuples?" -msgstr "" +msgstr "為何 Python 允許在串列和元組末端加上逗號?" #: ../../faq/design.rst:741 msgid "" "Python lets you add a trailing comma at the end of lists, tuples, and " "dictionaries::" msgstr "" +"Python 允許你在串列、元組和字典的結尾加上逗號:\n" +"\n" +"::" #: ../../faq/design.rst:752 msgid "There are several reasons to allow this." @@ -983,12 +1296,17 @@ msgid "" "remember to add a comma to the previous line. The lines can also be " "reordered without creating a syntax error." msgstr "" +"當你要把串列、元組或字典的值寫成多行時,這樣做會讓你新增元素時較為方便,因為" +"你不需要在前一行加上逗號。這幾行的值也可以被重新排序,而不會導致語法錯誤。" #: ../../faq/design.rst:759 msgid "" "Accidentally omitting the comma can lead to errors that are hard to " "diagnose. For example::" msgstr "" +"不小心遺漏了逗號會導致難以發現的錯誤,例如:\n" +"\n" +"::" #: ../../faq/design.rst:769 msgid "" @@ -996,9 +1314,11 @@ msgid "" "\"fee\", \"fiefoo\" and \"fum\". Always adding the comma avoids this source " "of error." msgstr "" +"這個串列看起來有四個元素,但他其實只有三個:「fee」、「fiefoo」、「fum」。永" +"遠記得加上逗號以避免這種錯誤。" #: ../../faq/design.rst:772 msgid "" "Allowing the trailing comma may also make programmatic code generation " "easier." -msgstr "" +msgstr "允許結尾逗號也讓生成的程式碼更容易產生。"