Thanks to visit codestin.com
Credit goes to github.com

Skip to content

Commit f911f93

Browse files
zhsjzhsj
committed
[po] auto sync bot
1 parent 64ceea3 commit f911f93

2 files changed

Lines changed: 42 additions & 15 deletions

File tree

‎faq/library.po‎

Lines changed: 39 additions & 12 deletions
Original file line numberDiff line numberDiff line change
@@ -335,24 +335,24 @@ msgstr "我的线程都没有运行，为什么？"
335335
msgid ""
336336
"As soon as the main thread exits, all threads are killed. Your main thread "
337337
"is running too quickly, giving the threads no time to do any work."
338-
msgstr ""
338+
msgstr "一旦主线程退出，所有的子线程都会被杀掉。你的主线程运行得太快了，子线程还没来得及工作。"
339339

340340
#: ../../faq/library.rst:256
341341
msgid ""
342342
"A simple fix is to add a sleep to the end of the program that's long enough "
343343
"for all the threads to finish::"
344-
msgstr ""
344+
msgstr "简单的解决方法是在程序中加一个时间足够长的 sleep，让子线程能够完成运行。"
345345

346346
#: ../../faq/library.rst:271
347347
msgid ""
348348
"But now (on many platforms) the threads don't run in parallel, but appear to"
349349
" run sequentially, one at a time! The reason is that the OS thread "
350350
"scheduler doesn't start a new thread until the previous thread is blocked."
351-
msgstr ""
351+
msgstr "但目前（在许多平台上）线程不是并行运行的，而是按顺序依次执行！原因是系统线程调度器在前一个线程阻塞之前不会启动新线程。"
352352

353353
#: ../../faq/library.rst:275
354354
msgid "A simple fix is to add a tiny sleep to the start of the run function::"
355-
msgstr ""
355+
msgstr "简单的解决方法是在运行函数的开始处加一个时间很短的 sleep。"
356356

357357
#: ../../faq/library.rst:288
358358
msgid ""
@@ -362,16 +362,21 @@ msgid ""
362362
" to the queue when it finishes, and let the main thread read as many tokens "
363363
"from the queue as there are threads."
364364
msgstr ""
365+
"比起用 :func:`time.sleep` 猜一个合适的等待时间，使用信号量机制会更好些。有一个办法是使用 :mod:`queue` 模块创建一个 "
366+
"queue 对象，让每一个线程在运行结束时 append 一个令牌到 queue 对象中，主线程中从 queue "
367+
"对象中读取与线程数量一致的令牌数量即可。"
365368

366369
#: ../../faq/library.rst:296
367370
msgid "How do I parcel out work among a bunch of worker threads?"
368-
msgstr ""
371+
msgstr "如何将任务分配给多个工作线程？"
369372

370373
#: ../../faq/library.rst:298
371374
msgid ""
372375
"The easiest way is to use the new :mod:`concurrent.futures` module, "
373376
"especially the :mod:`~concurrent.futures.ThreadPoolExecutor` class."
374377
msgstr ""
378+
"最简单的方法是使用新的 :mod:`concurrent.futures` 模块，尤其是其中的 "
379+
":mod:`~concurrent.futures.ThreadPoolExecutor` 类。"
375380

376381
#: ../../faq/library.rst:301
377382
msgid ""
@@ -382,24 +387,27 @@ msgid ""
382387
"a ``.get()`` method to return them. The class will take care of the locking"
383388
" necessary to ensure that each job is handed out exactly once."
384389
msgstr ""
390+
"或者，如果你想更好地控制分发算法，你也可以自己写逻辑实现。使用 :mod:`queue` "
391+
"模块来创建任务列表队列。:class:`~queue.Queue` 类维护一个了一个存有对象的列表，提供了 ``.put(obj)`` "
392+
"方法添加元素，并且可以用 ``.get()`` 方法获取元素。这个类会使用必要的加锁操作，以此确保每个任务只会执行一次。"
385393

386394
#: ../../faq/library.rst:308
387395
msgid "Here's a trivial example::"
388-
msgstr ""
396+
msgstr "这是一个简单的例子："
389397

390398
#: ../../faq/library.rst:346
391399
msgid "When run, this will produce the following output:"
392-
msgstr ""
400+
msgstr "运行时会产生如下输出："
393401

394402
#: ../../faq/library.rst:364
395403
msgid ""
396404
"Consult the module's documentation for more details; the "
397405
":class:`~queue.Queue` class provides a featureful interface."
398-
msgstr ""
406+
msgstr "查看模块的文档以获取更多信息；:class:`~queue.Queue` 类提供了多种接口。"
399407

400408
#: ../../faq/library.rst:369
401409
msgid "What kinds of global value mutation are thread-safe?"
402-
msgstr ""
410+
msgstr "怎样修改全局变量是线程安全的？"
403411

404412
#: ../../faq/library.rst:371
405413
msgid ""
@@ -410,6 +418,9 @@ msgid ""
410418
"instruction and therefore all the C implementation code reached from each "
411419
"instruction is therefore atomic from the point of view of a Python program."
412420
msgstr ""
421+
"Python VM 内部会使用 :term:`全局解释器锁` （GIL）来确保同一时间只有一个线程运行。通常 Python "
422+
"只会在字节码指令之间切换线程；切换的频率可以通过设置 :func:`sys.setswitchinterval` 指定。从 Python "
423+
"程序的角度来看，每一条字节码指令以及每一条指令对应的 C 代码实现都是原子的。"
413424

414425
#: ../../faq/library.rst:378
415426
msgid ""
@@ -418,16 +429,18 @@ msgid ""
418429
"shared variables of built-in data types (ints, lists, dicts, etc) that "
419430
"\"look atomic\" really are."
420431
msgstr ""
432+
"理论上说，具体的结果要看具体的 PVM 字节码实现对指令的解释。而实际上，对内建类型（int，list，dict "
433+
"等）的共享变量的“类原子”操作都是原子的。"
421434

422435
#: ../../faq/library.rst:383
423436
msgid ""
424437
"For example, the following operations are all atomic (L, L1, L2 are lists, "
425438
"D, D1, D2 are dicts, x, y are objects, i, j are ints)::"
426-
msgstr ""
439+
msgstr "举例来说，下面的操作是原子的（L、L1、L2 是列表，D、D1、D2 是字典，x、y 是对象，i，j 是 int 变量）："
427440

428441
#: ../../faq/library.rst:398
429442
msgid "These aren't::"
430-
msgstr ""
443+
msgstr "这些不是原子的："
431444

432445
#: ../../faq/library.rst:405
433446
msgid ""
@@ -436,10 +449,12 @@ msgid ""
436449
" affect things. This is especially true for the mass updates to "
437450
"dictionaries and lists. When in doubt, use a mutex!"
438451
msgstr ""
452+
"覆盖其他对象的操作会在其他对象的引用计数变成 0 时触发其 :meth:`__del__` "
453+
"方法，这可能会产生一些影响。对字典和列表进行大量操作时尤其如此。如果有疑问的话，使用互斥锁！"
439454

440455
#: ../../faq/library.rst:412
441456
msgid "Can't we get rid of the Global Interpreter Lock?"
442-
msgstr ""
457+
msgstr "不能删除全局解释器锁吗？"
443458

444459
#: ../../faq/library.rst:416
445460
msgid ""
@@ -448,6 +463,8 @@ msgid ""
448463
"multi-threaded Python program effectively only uses one CPU, due to the "
449464
"insistence that (almost) all Python code can only run while the GIL is held."
450465
msgstr ""
466+
":term:`全局解释器锁` （GIL）通常被视为 Python 在高端多核服务器上开发时的阻力，因为（几乎）所有 Python 代码只有在获取到 "
467+
"GIL 时才能运行，所以多线程的 Python 程序只能有效地使用一个 CPU。"
451468

452469
#: ../../faq/library.rst:421
453470
msgid ""
@@ -460,6 +477,10 @@ msgid ""
460477
"performance (at least 30% slower), due to the amount of fine-grained locking"
461478
" necessary to compensate for the removal of the GIL."
462479
msgstr ""
480+
"在 Python 1.5 时代，Greg Stein 开发了一个完整的补丁包（“free threadings” 补丁），移除了 "
481+
"GIL，并用粒度更合适的锁来代替。Adam Olsen 最近也在他的 `python-safethread "
482+
"<https://code.google.com/archive/p/python-safethread>`_ "
483+
"项目里做了类似的实验。不幸的是，由于为了移除 GIL 而使用了大量细粒度的锁，这两个实验在单线程测试中的性能都有明显的下降（至少慢 30%）。"
463484

464485
#: ../../faq/library.rst:429
465486
msgid ""
@@ -471,6 +492,10 @@ msgid ""
471492
":mod:`multiprocessing` module provides a lower-level API in case you want "
472493
"more control over dispatching of tasks."
473494
msgstr ""
495+
"但这并意味着你不能在多核机器上很好地使用 Python！你只需将任务划分为多*进程*，而不是多*线程*。新的 "
496+
":mod:`concurrent.futures` 模块中的 "
497+
":class:`~concurrent.futures.ProcessPoolExecutor` "
498+
"类提供了一个简单的方法；如果你想对任务分发做更多控制，可以使用 :mod:`multiprocessing` 模块提供的底层 API。"
474499

475500
#: ../../faq/library.rst:437
476501
msgid ""
@@ -480,6 +505,8 @@ msgid ""
480505
"work done. Some standard library modules such as :mod:`zlib` and "
481506
":mod:`hashlib` already do this."
482507
msgstr ""
508+
"恰当地使用 C 拓展也很有用；使用 C 拓展处理耗时较久的任务时，拓展可以在线程执行 C 代码时释放 GIL，让其他线程执行。:mod:`zlib` 和"
509+
" :mod:`hashlib` 等标准库模块已经这样做了。"
483510

484511
#: ../../faq/library.rst:443
485512
msgid ""

‎library/2to3.po‎

Lines changed: 3 additions & 3 deletions
Original file line numberDiff line numberDiff line change
@@ -499,12 +499,12 @@ msgid ""
499499
":func:`next` function. It also renames :meth:`next` methods to "
500500
":meth:`~iterator.__next__`."
501501
msgstr ""
502-
"将迭代器的 :meth:`iterator.next` 方法调用转为 :func:`next` 函数。也会将 :meth:`next` 方法重命名为 "
503-
":meth:`iterator.__next__`。"
502+
"将迭代器的 :meth:`~iterator.next` 方法调用转为 :func:`next` 函数。也会将 :meth:`next` 方法重命名为 "
503+
":meth:`~iterator.__next__`。"
504504

505505
#: ../../library/2to3.rst:338
506506
msgid "Renames :meth:`__nonzero__` to :meth:`~object.__bool__`."
507-
msgstr "将 :meth:`__nonzero__` 转换为 :meth:`object.__bool__`。"
507+
msgstr "将 :meth:`__nonzero__` 转换为 :meth:`~object.__bool__`。"
508508

509509
#: ../../library/2to3.rst:342
510510
msgid "Converts octal literals into the new syntax."

0 commit comments

Comments
 (0)