8000 fix: compile error due to lack of spaces · python/python-docs-zh-tw@9317d96 · GitHub
[go: up one dir, main page]

Skip to content

Commit 9317d96

Browse files
committed
fix: compile error due to lack of spaces
1 parent ef7cb62 commit 9317d96

File tree

1 file changed

+13
-13
lines changed

1 file changed

+13
-13
lines changed

faq/design.po

Lines changed: 13 additions & 13 deletions
Original file line numberDiff line numberDiff line change
@@ -9,7 +9,7 @@ msgstr ""
99
"Project-Id-Version: Python 3.10\n"
1010
"Report-Msgid-Bugs-To: \n"
1111
"POT-Creation-Date: 2022-07-06 00:17+0000\n"
12-
"PO-Revision-Date: 2022-08-27 18:01+0800\n"
12+
"PO-Revision-Date: 2022-08-29 22:27+0800\n"
1313
"Last-Translator: Adrian Liaw <adrianliaw2000@gmail.com>\n"
1414
"Language-Team: Chinese - TAIWAN (https://github.com/python/python-docs-zh- 10000 "
1515
"tw)\n"
@@ -61,7 +61,7 @@ msgid ""
6161
"decremented even for ``x > y``."
6262
msgstr ""
6363
"如果條件為真,只有 ``x++`` 陳述式會被執行,但縮排會讓很多人對他有不同的理解。"
64-
"即使是資深的 C 語言開發者有時也會盯著他許久,思考為何即便 ``x > y``,但 "
64+
"即使是資深的 C 語言開發者有時也會盯著他許久,思考為何即便 ``x > y``\\ ,但 "
6565
"``y`` 還是減少了。"
6666

6767
#: ../../faq/design.rst:31
@@ -334,11 +334,11 @@ msgid ""
334334
"mapping has a get() or keys() method, or something that isn't a file has a "
335335
"write() method."
336336
msgstr ""
337-
"(二) 當我看到一段程式碼寫著 len(x),我*知道*他要找某個東西的長度。這告訴了"
338-
"我兩件事:結果是一個整數、參數是某種容器。相對地,當我看到 x.len(),我必須先"
339-
"知道 x 是某種容器,並實作了一個介面或是繼承了一個有標準 len() 的類別。遇到一"
340-
"個沒有實作映射 (mapping) 的類別卻有 get() 或 keys() 方法,或是不是檔案但卻有 "
341-
"write() 方法時,我們偶爾會覺得困惑。"
337+
"(二) 當我看到一段程式碼寫著 len(x),我\\ *知道*\\ 他要找某個東西的長度。"
338+
"告訴了我兩件事:結果是一個整數、參數是某種容器。相對地,當我看到 x.len(),"
339+
"必須先知道 x 是某種容器,並實作了一個介面或是繼承了一個有標準 len() 的類別。"
340+
"遇到一個沒有實作映射 (mapping) 的類別卻有 get() 或 keys() 方法,或是不是檔案"
341+
"但卻有 write() 方法時,我們偶爾會覺得困惑。"
342342

343343
#: ../../faq/design.rst:189
344344
msgid "https://mail.python.org/pipermail/python-3000/2006-November/004643.html"
@@ -619,7 +619,7 @@ msgid ""
619619
"possibly long intervals."
620620
msgstr ""
621621
"實際上,使用 CPython 的參照計次 (reference counting) 和解構方案 (destructor "
622-
"scheme),每個對 *f* 的新指派都會關閉前面打開的檔案。然而用傳統的垃圾回收 "
622+
"scheme),每個對\\ *f*\\ 的新指派都會關閉前面打開的檔案。然而用傳統的垃圾回收 "
623623
"(GC) 的話,這些檔案物件只會在不固定且有可能很長的時間後被收集(並關閉)。"
624624

625625
#: ../../faq/design.rst:359
@@ -647,8 +647,8 @@ msgid ""
647647
"Python to work with it.)"
648648
msgstr ""
649649
"第一,這並不是 C 的標準功能,因此他的可攜性低。(對,我們知道 Boehm GC 函式"
650-
"庫。他有可相容於*大多數*平台的組合語言程式碼,但依然不是全部,而即便它大多數"
651-
"是通透的,也並不完全,要讓它跟 Python 相容還是需要做一些修補。)"
650+
"庫。他有可相容於\\ *大多數*\\ 平台的組合語言程式碼,但依然不是全部,而即便它"
651+
"大多數是通透的,也並不完全,要讓它跟 Python 相容還是需要做一些修補。)"
652652

653653
#: ../../faq/design.rst:377
654654
msgid ""
@@ -661,9 +661,9 @@ msgid ""
661661
msgstr ""
662662
"傳統的垃圾收集 (GC) 在 Python 被嵌入其他應用程式時也成了一個問題。在獨立的 "
663663
"Python 程式裡當然可以把標準的 malloc() 和 free() 換成 GC 函式庫提供的其他版"
664-
"本;但一個嵌著 Python 的應用程式可能想用*自己*的 malloc() 和 free() 替代品,"
665-
"而不是用 Python 的。以現在來說,CPython 和實作 malloc() 和 free() 的程式相處"
666-
"融洽。"
664+
"本;但一個嵌著 Python 的應用程式可能想用\\ *自己*\\ 的 malloc() 和 free() "
665+
"代品,而不是用 Python 的。以現在來說,CPython 和實作 malloc() 和 free() 的程"
666+
"式相處融洽。"
667667

668668
#: ../../faq/design.rst:386
669669
msgid "Why isn't all memory freed when CPython exits?"

0 commit comments

Comments
 (0)
0