@@ -12,7 +12,7 @@ msgid ""
12
12
msgstr ""
13
13
"Project-Id-Version : Python 3.10\n "
14
14
"Report-Msgid-Bugs-To : \n "
15
- "POT-Creation-Date : 2024-06-07 15:58 +0000\n "
15
+ "POT-Creation-Date : 2024-06-14 20:08 +0000\n "
16
16
"PO-Revision-Date : 2022-11-05 17:23+0000\n "
17
17
"
Last-Translator :
Rafael Fontenelle <[email protected] >, 2024\n "
18
18
"Language-Team : Chinese (China) (https://app.transifex.com/python-doc/teams/5390/zh_CN/)\n "
@@ -45,8 +45,8 @@ msgid ""
45
45
"useful changes, and points out a few incompatible changes that may require "
46
46
"rewriting code."
47
47
msgstr ""
48
- "Python "
49
- "2.0的新版本于2000年10月16日发布。本文将介绍2.0版本中的一些令人兴奋的新功能,重点介绍一些其他有用的更改,并指出一些可能需要重写代码的不兼容更改 。"
48
+ " 新的发行版 Python 2.0 发布于2000年10月16 日。本文介绍了 Python 2.0 "
49
+ "中令人兴奋的新功能,着重描述了一些其他有用的更改,并指出了一些可能需要重写代码的不兼容更改 。"
50
50
51
51
#: ../../whatsnew/2.0.rst:20
52
52
msgid ""
@@ -158,8 +158,11 @@ msgid ""
158
158
"notification e-mail messages that are completely unhelpful, so Ka-Ping Yee "
159
159
"wrote an HTML screen-scraper that sends more useful messages."
160
160
msgstr ""
161
- "转向使用SourceForge的服务显著提高了开发速度。补丁现在由原提交者以外的人提交、评论、修改,并在不同人员之间来回传递,直到补丁被认为值得检查。错误在一个中央位置被跟踪,并可以分配给特定人员进行修复,我们还可以统计未解决错误的数量来衡量进度。这并不是没有代价的:开发人员现在需要处理更多的电子邮件,关注更多的邮件列表,并且为新环境编写了专门的工具。例如,SourceForge发送的默认补丁和错误通知电子邮件完全无用,所以Ka-"
162
- "Ping Yee编写了一个HTML屏幕抓取器,以发送更有用的信息"
161
+ "转向使用 SourceForge 的服务显著提高了开发速度。 "
162
+ "补丁现在由原提交者以外的人提交、评论、修改,并在不同人员之间来回传递,直到补丁被认为值得检入。 "
163
+ "程序错误在一个中心位置被跟踪,并可以分配给特定人员进行修复,我们还可以统计未解决程序错误的数量来衡量进度。 "
164
+ "这并不是没有代价的:开发人员现在需要处理更多的电子邮件,关注更多的邮件列表,并且需要为新环境编写专门的工具。 例如,SourceForge "
165
+ "发送的默认补丁和错误通知电子邮件完全无用,所以 Ka-Ping Yee 编写了一个 HTML 屏幕抓取器以便发送更有用的信息。"
163
166
164
167
#: ../../whatsnew/2.0.rst:95
165
168
msgid ""
@@ -175,10 +178,10 @@ msgid ""
175
178
"can still ignore the result of a vote, and approve or reject a change even "
176
179
"if the community disagrees with him."
177
180
msgstr ""
178
- "添加代码的便利性引发了一些初期的成长痛苦,比如代码在准备好之前或未经开发者团队明确同意就被检入。现在形成的审批流程有点类似于Apache集团使用的流程。开发者可以对补丁投票:+1、+0、-0 "
179
- " 或 "
180
- "-1;+1和-1表示接受或拒绝,而+0和-0则表示开发者对变更大多持无所谓的态度, 但略有正面或负面的倾向。与Apache模型最显著的变化是投票本质上是咨询性的,让拥有终身仁慈独裁者地位的Guido "
181
- " van Rossum了解总体意见。 他仍然可以忽略投票结果,并批准或拒绝变更,即使社区不同意他的决定。"
181
+ "添加代码的便利性引发了一些初期的成长痛苦,比如代码在准备好之前或未经开发者团队明确同意就被检入。 现在形成的审批流程有点类似于 Apache "
182
+ "团队所使用的流程。 开发者可以对补丁投票:+1、+0、-0 或 -1;+1 和 -1 表示接受或拒绝,而 +0 和 -0 "
183
+ "则表示开发者对变更大多持无所谓的态度, 但略有正面或负面的倾向。 与 Apache 模型最显著的变化是投票本质上是咨询性的,让拥有终身仁慈独裁者地位的 "
184
+ "Guido van Rossum 了解总体意见。 他仍然可以忽略投票结果,并批准或拒绝变更,即使社区不同意他的决定。"
182
185
183
186
#: ../../whatsnew/2.0.rst:106
184
187
msgid ""
@@ -193,9 +196,11 @@ msgid ""
193
196
" accepting or rejecting the proposal. Quoting from the introduction to "
194
197
":pep:`1`, \" PEP Purpose and Guidelines\" :"
195
198
msgstr ""
196
- "实际产生补丁是添加新功能的最后一步,与之前指定一个号的设计相比,这通常比较容易。对于新功能的讨论往往会变成冗长的邮件列表线程,使讨论难以跟踪,并且没有人能够阅读每一条发给python-"
197
- "dev的帖子。因此,建议了一个相对正式的流程来编写Python增强提案(PEP),该流程借鉴了互联网RFC流程。PEP是描述拟议新功能的草案文件,并不断修改,知道社区达成共识,接受或拒绝该提案。引用自"
198
- " :pep:`1` 的介绍部分,\" PEP目的和指南\" :"
199
+ "实际产生补丁是添加新功能的最后一步,与之前指定一个好的设计相比,这通常比较容易。 "
200
+ "对于新功能的讨论往往会变成冗长的邮件列表帖子,使讨论难以跟踪,并且没有人能够阅读每一条发给 python-dev 的帖子。 "
201
+ "因此,建议了一个相对正式的流程来编写 Python 增强提案(PEP),该流程借鉴了互联网 RFC 流程。 PEP "
202
+ "是描述拟议新特性的草案文件,并不断修改,直到社区达成共识,接受或拒绝该提案。 引用自 :pep:`1` 的介绍部分 \" PEP Purpose and "
203
+ "Guidelines\" :"
199
204
200
205
#: ../../whatsnew/2.0.rst:120
201
206
msgid ""
@@ -204,7 +209,8 @@ msgid ""
204
209
"for Python. The PEP should provide a concise technical specification of the"
205
210
" feature and a rationale for the feature."
206
211
msgstr ""
207
- "PEP代表Python增强提案。PEP是一份设计文档,为Python社区提供信息,或描述Python的新功能。PEP应提供该功能的简明技术规范和该功能的理由。"
212
+ "PEP 是 Python Enhancement Proposal 的缩写。 一个 PEP 就是一份设计文档,用来向 Python "
213
+ "社区提供信息,或描述一个 Python 新增特性。 PEP 应当提供对所提议特性的精确的技术规格和原理说明。"
208
214
209
215
#: ../../whatsnew/2.0.rst:125
210
216
msgid ""
@@ -213,7 +219,8 @@ msgid ""
213
219
"decisions that have gone into Python. The PEP author is responsible for "
214
220
"building consensus within the community and documenting dissenting opinions."
215
221
msgstr ""
216
- "我们打算将PEP作为提出新功能、收集社区对某个问题的反馈以及记录Python设计决策的主要机制。PEP的作者负责在社区内建立公式并记录不同意见。"
222
+ "我们打算将 PEP 作为提出新特性建议、收集社区对特定问题意见以及为必须加入 Python 的设计决策编写文档的首选机制。 PEP "
223
+ "的作者有责任在社区内部建立共识,并应将对立的观点也记入文档。"
217
224
218
225
#: ../../whatsnew/2.0.rst:130
219
226
msgid ""
@@ -236,8 +243,8 @@ msgid ""
236
243
"instead of the 8-bit number used by ASCII, meaning that 65,536 distinct "
237
244
"characters can be supported."
238
245
msgstr ""
239
- "Python 2.0 "
240
- "中最大的新增功能是引入了一种新的基础数据类型:Unicode字符串。Unicode使用16位数字表示字符,而不是ASCII使用的8位数字,这意味着可以支持65,536个不同的字符 。"
246
+ "Python 2.0 中最大的新特性是引入了一种新的基本数据类型:Unicode 字符串。 Unicode 使用 16 位二进制数表示字符,而不是 "
247
+ "ASCII 所使用的 8 位,这意味着可以支持 65,536 个不同的字符 。"
241
248
242
249
#: ../../whatsnew/2.0.rst:148
243
250
msgid ""
@@ -248,9 +255,9 @@ msgid ""
248
255
"was written up as :pep:`100`, \" Python Unicode Integration\" . This article "
249
256
"will simply cover the most significant points about the Unicode interfaces."
250
257
msgstr ""
251
- "Unicode支持的最终接口是通过在python-dev邮件列表上无数次激烈的讨论达成的,主要由Marc -André Lemburg基于Fredrik "
252
- "Lundh的Unicode字符串类型实现来完成。详细的接口被写成了文档 :pep:`100` \" Python中Unicode的整合 \" 。 "
253
- "这篇文章只涵盖关于Unicode接口的最重要的要点 。"
258
+ "Unicode 支持的最终接口是通过在 python-dev 邮件列表上无数次激烈的讨论达成的,主要由 Marc -André Lemburg 基于 "
259
+ "Fredrik Lundh 的 Unicode 字符串类型实现来完成。 详细的接口说明被写成了 :pep:`100` \" Python Unicode "
260
+ "Integration \" 。 这篇文章只简单地涵盖关于 Unicode 接口的最重要信息 。"
254
261
255
262
#: ../../whatsnew/2.0.rst:155
256
263
msgid ""
@@ -275,11 +282,11 @@ msgid ""
275
282
"installation by calling the ``sys.setdefaultencoding(encoding)`` function in"
276
283
" a customized version of :file:`site.py`."
277
284
msgstr ""
278
- "Unicode字符串和普通字符串一样 ,是一种不可变的序列类型。它们可以被索引和切片,但不能原地修改。Unicode字符串有一个 ``encode( "
279
- "[encoding] )`` 方法,该方法返回一个以所需编码表示的8位字符串。编码通过字符串命名 ,如 "
280
- "``'ascii'``、``'utf-8'``、``'iso-8859-1'`` "
281
- "或其他。为实现和注册新的编码定义了一个编解码器API,这些编码随后可在整个Python程序中使用。如果未指定编码,默认编码通常是7位ASCII码,不过可以通过在自定义版本的 "
282
- " :file:`site.py` 模块中调用 ``sys.setdefaultencoding(encoding)`` 函数来更改默认编码 。"
285
+ "Unicode 字符串和常规字符串一样 ,是一种不可变的序列类型。 它们可以被索引和切片,但不能原地修改。 Unicode 字符串有一个 "
286
+ "``encode( [encoding] )`` 方法,该方法返回一个以所需编码格式表示的 8 位字符串。 编码格式通过字符串命名 ,如 "
287
+ "``'ascii'``、``'utf-8'``、``'iso-8859-1'`` 等等。 为实现和注册新的编码格式定义了一个编解码器 "
288
+ "API,这些编码格式随后可在整个 Python 程序中使用。 如果未指定编码格式,默认编码格式通常是 7 位 ASCII,不过这可以通过在自定义版本的 "
289
+ ":file:`site.py` 模块中调用 ``sys.setdefaultencoding(encoding)`` 函数来更改 。"
283
290
284
291
#: ../../whatsnew/2.0.rst:172
285
292
msgid ""
@@ -317,10 +324,10 @@ msgid ""
317
324
"errors to be silently ignored and ``'replace'`` uses U+FFFD, the official "
318
325
"replacement character, in case of any problems."
319
326
msgstr ""
320
- "函数 ``unicode(string [, encoding] [, errors] )`` "
321
- "从8位字符串创建一个Unicode字符串。 ``encoding`` 是一个指定使用编码的字符串 。``errors`` "
322
- "参数指定如何处理当前编码中无效的字符;将 ``'strict '`` 作为值传递会在任何编码错误时引发异常,而 ``'ignore '`` "
323
- "会静默忽略错误,``'replace'`` 则在出现问题时使用U+FFFD, 即官方的替换字符。"
327
+ "函数 ``unicode(string [, encoding] [, errors] )`` 从 8 位字符串创建一个 Unicode 字符串。 "
328
+ "``encoding`` 是一个指定使用编码格式的字符串 。``errors`` 参数指定如何处理当前编码格式中无效的字符;传入 ``'strict'`` "
329
+ " 作为参数值会在有任何编码错误时引发异常,而 ``'ignore '`` 会静默忽略错误, ``'replace '`` 则在出现问题时使用 U+FFFD "
330
+ "即官方的替换字符。"
324
331
325
332
#: ../../whatsnew/2.0.rst:192
326
333
msgid ""
@@ -354,7 +361,7 @@ msgid ""
354
361
"4-element tuple: ``(encode_func, decode_func, stream_reader, "
355
362
"stream_writer)``."
356
363
msgstr ""
357
- ":mod:`codecs` 模块包含查找现有编码和注册新编码的函数。除非你想实现一个新的编码 ,否则你最常使用的是 "
364
+ ":mod:`codecs` 模块包含查找现有编码格式和注册新编码格式的函数。 除非你想实现一个新的编码格式 ,否则你最常使用的是 "
358
365
"``codecs.lookup(encoding)`` 函数,它返回一个 4 元素的元组: ``(encode_func, decode_func, "
359
366
"stream_reader, stream_writer)``。"
360
367
@@ -377,7 +384,7 @@ msgid ""
377
384
"8-bit string was consumed."
378
385
msgstr ""
379
386
"*decode_func* 与 *encode_func* 相反,它接受一个 8 位字符串并返回一个 2 元组 ``(ustring, "
380
- "length)``,其中 *ustring* 是转换得到的 Unicode 字符串,*length* 是一个整数,表示消耗了多少 8 位的字符串 。"
387
+ "length)``,其中 *ustring* 是转换得到的 Unicode 字符串,*length* 是一个整数,表示消耗了多少 8 位字符串 。"
381
388
382
389
#: ../../whatsnew/2.0.rst:219
383
390
msgid ""
@@ -469,7 +476,7 @@ msgstr ""
469
476
470
477
#: ../../whatsnew/2.0.rst:292
471
478
msgid "List comprehensions have the form::"
472
- msgstr "列表推导式有如下的格式: "
479
+ msgstr "列表推导式的形式如下:: "
473
480
474
481
#: ../../whatsnew/2.0.rst:299
475
482
msgid ""
@@ -852,10 +859,11 @@ msgid ""
852
859
"of :exc:`NameError`, so any existing code that expects :exc:`NameError` to "
853
860
"be raised should still work. ::"
854
861
msgstr ""
855
- "已经尝试解决Python的一个问题,即当代码在局部变量赋值之前引用该变量时,会引发经常令人困惑的 :exc:`NameError` "
856
- "异常。例如,以下代码在1.5.2和2.0中都会在 ``print`` 语句上引发异常;在1.5.2中,会引发 :exc:`NameError` "
857
- "异常,而在2.0中,会引发一个新的 :exc:`UnboundLocalError` 异常。:exc:`UnboundLocalError` 是 "
858
- ":exc:`NameError` 的子类,因此任何期望引发 :exc:`NameError` 的现有代码应该仍然可以正常工作。"
862
+ "已经尝试解决 Python 的一个问题,即当代码在局部变量赋值之前引用该变量时,会引发经常令人困惑的 :exc:`NameError` "
863
+ "异常。例如,以下代码在 1.5.2 和 2.0 中都会在 ``print`` 语句上引发异常;在 1.5.2 中,会引发 "
864
+ ":exc:`NameError` 异常,而在 2.0 中,会引发一个新的 :exc:`UnboundLocalError` 异常。 "
865
+ ":exc:`UnboundLocalError` 是 :exc:`NameError` 的子类,因此任何期望引发 :exc:`NameError` "
866
+ "的现有代码应该仍然可以正常工作。"
859
867
860
868
#: ../../whatsnew/2.0.rst:595
861
869
msgid ""
@@ -1514,7 +1522,7 @@ msgid ""
1514
1522
"A number of new modules were added. We'll simply list them with brief "
1515
1523
"descriptions; consult the 2.0 documentation for the details of a particular "
1516
1524
"module."
1517
- msgstr "添加了许多新模块,我们将简单列出它们并附上简要概述;有关特定模块的详细信息,请查阅2.0文档 。"
1525
+ msgstr "添加了许多新模块,我们将简单列出它们并附上简要概述;有关特定模块的详细信息,请查阅 2.0 文档 。"
1518
1526
1519
1527
#: ../../whatsnew/2.0.rst:1080
1520
1528
msgid ""
@@ -1632,7 +1640,7 @@ msgid ""
1632
1640
"supported by the :mod:`gzip` module) (Contributed by James C. Ahlstrom.)"
1633
1641
msgstr ""
1634
1642
":mod:`zipfile` 模块:用于读取和写入 ZIP 格式的归档文件。 这些归档文件是由 DOS/Windows 上的 "
1635
- ":program:`PKZIP` 或 Unix 上的 :program:`zip` 生成的,不要与 :program:`gzip` 格式文件(由 "
1643
+ ":program:`PKZIP` 或 Unix 上的 :program:`zip` 生成的,不要与 :program:`gzip` 格式文件(由 "
1636
1644
":mod:`gzip` 支持)混淆。 (由 James C. Ahlstrom 贡献。)"
1637
1645
1638
1646
#: ../../whatsnew/2.0.rst:1142
0 commit comments