@@ -9,7 +9,7 @@ msgstr ""
9
9
"Project-Id-Version : Python 3.10\n "
10
10
"Report-Msgid-Bugs-To : \n "
11
11
"POT-Creation-Date : 2022-07-06 00:17+0000\n "
12
- "PO-Revision-Date : 2022-08-29 22:27 +0800\n "
12
+ "PO-Revision-Date : 2022-08-31 22:38 +0800\n "
13
13
"Last-Translator : Adrian Liaw <adrianliaw2000@gmail.com>\n "
14
14
"Language-Team : Chinese - TAIWAN (https://github.com/python/python-docs-zh- "
15
15
"tw)\n "
@@ -39,17 +39,17 @@ msgid ""
39
39
"elegant and contributes a lot to the clarity of the average Python program. "
40
40
"Most people learn to love this feature after a while."
41
41
msgstr ""
42
- "Guido van Rossum 相信使用縮排來分組超級優雅,並且對提高一般 Python 程式的清晰度有許多貢獻。 "
43
- "許多人在學習一段時間之後就愛上了這個功能。"
42
+ "Guido van Rossum 相信使用縮排來分組超級優雅,並且對提高一般 Python 程式的清晰 "
43
+ "度有許多貢獻。 許多人在學習一段時間之後就愛上了這個功能。"
44
44
45
45
#: ../../faq/design.rst:17
46
46
msgid ""
47
47
"Since there are no begin/end brackets there cannot be a disagreement between "
48
48
"grouping perceived by the parser and the human reader. Occasionally C "
49
49
"programmers will encounter a fragment of code like this::"
50
50
msgstr ""
51
- "因為沒有開始/結束括號,因此剖析器和人類讀者感知到的分組就不存在分歧。"
52
- "偶爾 C 語言的程式設計師會遇到這樣的程式碼片段:\n"
51
+ "因為沒有開始/結束括號,因此剖析器和人類讀者感知到的分組就不存在分歧。偶爾 C "
52
+ "語言的程式設計師會遇到這樣的程式碼片段:\n"
53
53
"\n"
54
54
"::"
55
55
@@ -64,7 +64,6 @@ msgstr ""
64
64
"即使是資深的 C 語言開發者有時也會盯著他許久,思考為何即便 ``x > y``\\ ,但 "
65
65
"``y`` 還是減少了。"
66
66
67
-
68
67
#: ../../faq/design.rst:31
69
68
msgid ""
70
69
"Because there are no begin/end brackets, Python is much less prone to coding-"
@@ -90,8 +89,8 @@ msgstr ""
90
89
"很多程式碼風格會把 begin/end 獨立放在一行。這會讓程式碼很長且浪費珍貴的螢幕空"
91
90
"間,要概覽程式時也變得較為困難。理想上來說,一個函式應該要佔一個螢幕(大概 "
92
91
"20 至 30 行)。20 行的 Python 程式碼比起 20 行的 C 程式碼可以做更多事。雖然沒"
93
- "有開頭與結尾的括號並非單一原因(沒有變數宣告及高階的資料型別同樣有關),但縮排式的 "
94
- "語法確實給了幫助 。"
92
+ "有開頭與結尾的括號並非單一原因(沒有變數宣告及高階的資料型別同樣有關),但縮 "
93
+ "排式的語法確實給了幫助 。"
95
94
96
95
#: ../../faq/design.rst:48
97
96
msgid "Why am I getting strange results with simple arithmetic operations?"
@@ -107,7 +106,8 @@ msgstr "為何浮點數運算如此不精確?"
107
106
108
107
#: ../../faq/design.rst:56
109
108
msgid "Users are often surprised by results like this::"
110
- msgstr "使用者時常對這樣的結果感到驚訝:\n"
109
+ msgstr ""
110
+ "使用者時常對這樣的結果感到驚訝:\n"
111
111
"\n"
112
112
"::"
113
113
@@ -192,8 +192,8 @@ msgid ""
192
192
"tuples and lists."
193
193
msgstr ""
194
194
"其一是效能:知道字串不可變動後,我們就可以在創造他的時候就分配好空間,而後他"
195
- "的儲存空間需求就是固定不變的。這也是元組 (tuple) 和串列 (list) 相異的其中一 "
196
- "個原因 。"
195
+ "的儲存空間需求就是固定不變的。這也是元組 (tuple) 和串列 (list) 相異的其中一個 "
196
+ "原因 。"
197
197
198
198
#: ../../faq/design.rst:104
199
199
msgid ""
@@ -382,9 +382,9 @@ msgid ""
382
382
"on names bound to strings there is no logical reason to make them "
383
383
"unavailable on literals."
384
384
msgstr ""
385
- "第一項這麼說:「用字串文本 (string literal) (字串常數)看起來真的很醜」,也許真的 "
386
- "如此 ,但字串文本就只是一個固定值。如果方法可以用在值為字串的變數上,"
387
- "那沒道理字串文本不能被使用 。"
385
+ "第一項這麼說:「用字串文本 (string literal) (字串常數)看起來真的很醜」,也 "
386
+ "許真的如此 ,但字串文本就只是一個固定值。如果方法可以用在值為字串的變數上,那 "
387
+ "沒道理字串文本不能被使用 。"
388
388
389
389
#: ../../faq/design.rst:215
390
390
msgid ""
@@ -591,15 +591,14 @@ msgstr ""
591
591
#: ../../faq/design.rst:341
592
592
msgid ""
593
593
"Other implementations (such as `Jython <https://www.jython.org>`_ or `PyPy "
594
- "<https://www.pypy.org>`_), however, can rely on a different mechanism such as "
595
- "a full-blown garbage collector. This difference can cause some subtle "
594
+ "<https://www.pypy.org>`_), however, can rely on a different mechanism such "
595
+ "as a full-blown garbage collector. This difference can cause some subtle "
596
596
"porting problems if your Python code depends on the behavior of the "
597
597
"reference counting implementation."
598
598
msgstr ""
599
599
"然而,在其他實作(像是 `Jython <https://www.jython.org>`_ 或 `PyPy <https://"
600
600
"www.pypy.org>`_)中,會使用像是成熟的垃圾收集器等不同機制。如果你的 Python 程"
601
- "式碼的表現取決於參照計次的實作,這個相異處會導致一些微"
602
- "小的移植問題。"
601
+ "式碼的表現取決於參照計次的實作,這個相異處會導致一些微小的移植問題。"
603
602
604
603
#: ../../faq/design.rst:347
605
604
msgid ""
@@ -618,9 +617,9 @@ msgid ""
618
617
"those file objects will only get collected (and closed) at varying and "
619
618
"possibly long intervals."
620
619
msgstr ""
621
- "實際上,使用 CPython 的參照計次和解構方案 (destructor "
622
- "scheme),每個對 \\ *f* \\ 的新指派都會關閉前面打開的檔案。然而用傳統的垃圾回收 "
623
- "(GC) 的話,這些檔案物件只會在不固定且有可能很長的時間後被收集 (並關閉)。"
620
+ "實際上,使用 CPython 的參照計次和解構方案 (destructor scheme),每個對 \\ *f* "
621
+ "\\ 的新指派都會關閉前面打開的檔案。然而用傳統的垃圾回收 (GC) 的話,這些檔案物 "
622
+ "件只會在不固定且有可能很長的時間後被收集 (並關閉)。"
624
623
625
624
#: ../../faq/design.rst:359
626
625
msgid ""
@@ -705,9 +704,9 @@ msgid ""
705
704
"numbers."
706
705
msgstr ""
707
706
"串列和元組在很多方面相當相似,但通常用在完全不同的地方。元組可以想成 Pascal "
708
- "的紀錄 (record) 或是 C 的結構 (struct),是一小群相關聯但可能是不同型別的資 "
709
- "料集合 ,以一組為單位進行操作。舉例來說,一個笛卡兒坐標系可以適當地表示成一個 "
710
- "有二或三個值的元組 。"
707
+ "的紀錄 (record) 或是 C 的結構 (struct),是一小群相關聯但可能是不同型別的資料 "
708
+ "集合 ,以一組為單位進行操作。舉例來說,一個笛卡兒坐標系可以適當地表示成一個有 "
709
+ "二或三個值的元組 。"
711
710
712
711
#: ../../faq/design.rst:409
713
712
msgid ""
@@ -746,8 +745,8 @@ msgid ""
746
745
"head structure."
747
746
msgstr ""
748
747
"CPython 的串列 (list) 事實上是可變長度的陣列 (array),而不是像 Lisp 語言的鏈"
749
- "接串列 (linked list)。實作上,他是一個連續的物件參照 (reference) 陣列,並把 "
750
- "指向此陣列的指標 (pointer) 和陣列長度存在串列的標頭結構內。"
748
+ "接串列 (linked list)。實作上,他是一個連續的物件參照 (reference) 陣列,並把指 "
749
+ "向此陣列的指標 (pointer) 和陣列長度存在串列的標頭結構內。"
751
750
752
751
#: ../../faq/design.rst:429
753
752
msgid ""
@@ -794,9 +793,9 @@ msgid ""
794
793
msgstr ""
795
794
"字典利用內建 :func:`hash` 函式,對每個鍵做雜湊計算。雜湊結果依據鍵的值和個別"
796
795
"執行緒 (processes) 的種子而有相當大的差距。例如,\" Python\" 的雜湊是 "
797
- "-539294296,而只差一個字的 \" python\" 則是 1142331976。雜湊結果接著被用來計算值 "
798
- "在內部陣列儲存的位置 。假設你存的鍵都有不同的雜湊值,那字典只需要常數時間 — 用 "
799
- "大 O 表示法 (Big-O notation) 就是 O(1) — 來找任意一個鍵。"
796
+ "-539294296,而只差一個字的 \" python\" 則是 1142331976。雜湊結果接著被用來計算 "
797
+ "值在內部陣列儲存的位置 。假設你存的鍵都有不同的雜湊值,那字典只需要常數時間 — "
798
+ "用大 O 表示法 (Big-O notation) 就是 O(1) — 來找任意一個鍵。"
800
799
801
800
#: ../../faq/design.rst:456
802
801
msgid "Why must dictionary keys be immutable?"
@@ -990,11 +989,10 @@ msgid ""
990
989
"`~collections.abc.MutableMapping`."
991
990
msgstr ""
992
991
"Python 2.6 加入了 :mod:`abc` 模組,讓你可以定義抽象基底類別 (Abstract Base "
993
- "Class, ABC)。你可以使用 :func:`isinstance` 和 :func:`issubclass` 來確認一"
994
- "個實例或是類別是否實作了某個抽象基底類別。而 :mod:`collections."
995
- "abc` 模組定義了一系列好用的抽象基底類別,像是 :class:`~collections.abc."
996
- "Iterable`、:class:`~collections.abc.Container` 和 :class:`~collections.abc."
997
- "MutableMapping`。"
992
+ "Class, ABC)。你可以使用 :func:`isinstance` 和 :func:`issubclass` 來確認一個實"
993
+ "例或是類別是否實作了某個抽象基底類別。而 :mod:`collections.abc` 模組定義了一"
994
+ "系列好用的抽象基底類別,像是 :class:`~collections.abc.Iterable`、:class:"
995
+ "`~collections.abc.Container` 和 :class:`~collections.abc.MutableMapping`。"
998
996
999
997
#: ../../faq/design.rst:570
1000
998
msgid ""
@@ -1229,9 +1227,9 @@ msgid ""
1229
1227
"iterator run to completion, no closing is needed. When it is, wrap it as "
1230
1228
"\" contextlib.closing(generator)\" in the 'with' statement."
1231
1229
msgstr ""
1232
- "出於技術原因,把產生器直接用作情境 (context) 管理器會無法正常運作。因為通常 "
1233
- "來說 ,產生器是被當成疊代器 (iterator),到最後完成時不需要被手動關閉。但如果你 "
1234
- "需要的話 ,你可以在 with 陳述式裡用「contextlib.closing(generator)」來包裝他。"
1230
+ "出於技術原因,把產生器直接用作情境 (context) 管理器會無法正常運作。因為通常來 "
1231
+ "說 ,產生器是被當成疊代器 (iterator),到最後完成時不需要被手動關閉。但如果你需 "
1232
+ "要的話 ,你可以在 with 陳述式裡用「contextlib.closing(generator)」來包裝他。"
1235
1233
1236
1234
#: ../../faq/design.rst:717
1237
1235
msgid "Why are colons required for the if/while/def/class statements?"
0 commit comments