88msgstr ""
99"Project-Id-Version : Python 3.14\n "
1010"Report-Msgid-Bugs-To : \n "
11- "POT-Creation-Date : 2025-10-05 14:11 +0000\n "
11+ "POT-Creation-Date : 2025-10-15 14:16 +0000\n "
1212"PO-Revision-Date : 2025-09-16 00:00+0000\n "
1313"Language-Team : German (https://app.transifex.com/python-doc/teams/5390/de/)\n "
1414"MIME-Version : 1.0\n "
@@ -27,15 +27,15 @@ msgid ""
2727msgstr ""
2828
2929msgid ""
30- "You might be curious about some key :mod:`!asyncio` concepts. You'll be "
31- "comfortably able to answer these questions by the end of this article :"
30+ "You might be curious about some key :mod:`!asyncio` concepts. By the end of "
31+ "this article, you'll be able to comfortably answer these questions:"
3232msgstr ""
3333
3434msgid "What's happening behind the scenes when an object is awaited?"
3535msgstr ""
3636
3737msgid ""
38- "How does :mod:`!asyncio` differentiate between a task which doesn't need CPU- "
38+ "How does :mod:`!asyncio` differentiate between a task which doesn't need CPU "
3939"time (such as a network request or file read) as opposed to a task that does "
4040"(such as computing n-factorial)?"
4141msgstr ""
@@ -67,7 +67,7 @@ msgstr ""
6767
6868msgid ""
6969"In part 1, we'll cover the main, high-level building blocks of :mod:`!"
70- "asyncio`: the event loop, coroutine functions, coroutine objects, tasks and "
70+ "asyncio`: the event loop, coroutine functions, coroutine objects, tasks, and "
7171"``await``."
7272msgstr ""
7373
@@ -91,7 +91,7 @@ msgid ""
9191"event loop will then select another job from its pool and invoke it. You can "
9292"*roughly* think of the collection of jobs as a queue: jobs are added and "
9393"then processed one at a time, generally (but not always) in order. This "
94- "process repeats indefinitely with the event loop cycling endlessly onwards. "
94+ "process repeats indefinitely, with the event loop cycling endlessly onwards. "
9595"If there are no more jobs pending execution, the event loop is smart enough "
9696"to rest and avoid needlessly wasting CPU cycles, and will come back when "
9797"there's more work to be done."
@@ -356,7 +356,7 @@ msgstr ""
356356msgid ""
357357"Generally speaking, when the awaited task finishes (``dig_the_hole_task``), "
358358"the original task or coroutine (``plant_a_tree()``) is added back to the "
359- "event loops to-do list to be resumed."
359+ "event loop's to-do list to be resumed."
360360msgstr ""
361361
362362msgid ""
@@ -394,7 +394,7 @@ msgstr ""
394394msgid ""
395395"The first statement in the coroutine ``main()`` creates ``task_b`` and "
396396"schedules it for execution via the event loop. Then, ``coro_a()`` is "
397- "repeatedly awaited. Control never cedes to the event loop which is why we "
397+ "repeatedly awaited. Control never cedes to the event loop, which is why we "
398398"see the output of all three ``coro_a()`` invocations before ``coro_b()``'s "
399399"output:"
400400msgstr ""
@@ -425,18 +425,18 @@ msgid ""
425425"This behavior of ``await coroutine`` can trip a lot of people up! That "
426426"example highlights how using only ``await coroutine`` could unintentionally "
427427"hog control from other tasks and effectively stall the event loop. :func:"
428- "`asyncio.run` can help you detect such occurences via the ``debug=True`` "
429- "flag which accordingly enables :ref:`debug mode <asyncio-debug-mode>`. Among "
430- "other things, it will log any coroutines that monopolize execution for 100ms "
431- "or longer."
428+ "`asyncio.run` can help you detect such occurrences via the ``debug=True`` "
429+ "flag, which enables :ref:`debug mode <asyncio-debug-mode>`. Among other "
430+ "things, it will log any coroutines that monopolize execution for 100ms or "
431+ "longer."
432432msgstr ""
433433
434434msgid ""
435435"The design intentionally trades off some conceptual clarity around usage of "
436436"``await`` for improved performance. Each time a task is awaited, control "
437437"needs to be passed all the way up the call stack to the event loop. That "
438- "might sound minor, but in a large program with many ``await``'s and a deep "
439- "callstack that overhead can add up to a meaningful performance drag."
438+ "might sound minor, but in a large program with many ``await`` statements and "
439+ "a deep call stack, that overhead can add up to a meaningful performance drag."
440440msgstr ""
441441
442442msgid "A conceptual overview part 2: the nuts and bolts"
@@ -460,7 +460,7 @@ msgid ""
460460"resume a coroutine. If the coroutine was paused and is now being resumed, "
461461"the argument ``arg`` will be sent in as the return value of the ``yield`` "
462462"statement which originally paused it. If the coroutine is being used for the "
463- "first time (as opposed to being resumed) ``arg`` must be ``None``."
463+ "first time (as opposed to being resumed), ``arg`` must be ``None``."
464464msgstr ""
465465
466466msgid ""
@@ -492,12 +492,12 @@ msgid ""
492492msgstr ""
493493
494494msgid ""
495- ":ref:`yield <yieldexpr>`, like usual, pauses execution and returns control "
496- "to the caller. In the example above, the ``yield``, on line 3, is called by "
495+ ":ref:`yield <yieldexpr>`, as usual, pauses execution and returns control to "
496+ "the caller. In the example above, the ``yield``, on line 3, is called by "
497497"``... = await rock`` on line 11. More broadly speaking, ``await`` calls the :"
498498"meth:`~object.__await__` method of the given object. ``await`` also does one "
499499"more very special thing: it propagates (or \" passes along\" ) any ``yield``\\ "
500- "s it receives up the call- chain. In this case, that's back to ``... = "
500+ "s it receives up the call chain. In this case, that's back to ``... = "
501501"coroutine.send(None)`` on line 16."
502502msgstr ""
503503
@@ -561,12 +561,12 @@ msgid ""
561561msgstr ""
562562
563563msgid ""
564- "A future has a few important attributes. One is its state which can be "
565- "either \" pending\" , \" cancelled\" or \" done\" . Another is its result, which "
564+ "A future has a few important attributes. One is its state, which can be "
565+ "either \" pending\" , \" cancelled\" , or \" done\" . Another is its result, which "
566566"is set when the state transitions to done. Unlike a coroutine, a future does "
567567"not represent the actual computation to be done; instead, it represents the "
568568"status and result of that computation, kind of like a status light (red, "
569- "yellow or green) or indicator."
569+ "yellow, or green) or indicator."
570570msgstr ""
571571
572572msgid ""
@@ -593,10 +593,10 @@ msgid ""
593593msgstr ""
594594
595595msgid ""
596- "This snippet registers a few tasks with the event loop and then awaits a "
597- "coroutine wrapped in a task: ``async_sleep(3)``. We want that task to finish "
598- "only after three seconds have elapsed, but without preventing other tasks "
599- "from running."
596+ "This snippet registers a few tasks with the event loop and then awaits the "
597+ "task created by ``asyncio.create_task``, which wraps the ``async_sleep(3)`` "
598+ "coroutine. We want that task to finish only after three seconds have "
599+ "elapsed, but without preventing other tasks from running."
600600msgstr ""
601601
602602msgid ""
@@ -645,8 +645,8 @@ msgid ""
645645msgstr ""
646646
647647msgid ""
648- "Below, we'll use a rather bare object, ``YieldToEventLoop()``, to ``yield`` "
649- "from ``__await__`` in order to cede control to the event loop. This is "
648+ "Below, we use a rather bare ``YieldToEventLoop()`` object to ``yield`` from "
649+ "its ``__await__`` method, ceding control to the event loop. This is "
650650"effectively the same as calling ``asyncio.sleep(0)``, but this approach "
651651"offers more clarity, not to mention it's somewhat cheating to use ``asyncio."
652652"sleep`` when showcasing how to implement it!"
@@ -658,12 +658,12 @@ msgid ""
658658"which runs the coroutine ``_sleep_watcher(...)``, will be invoked once per "
659659"full cycle of the event loop. On each resumption, it'll check the time and "
660660"if not enough has elapsed, then it'll pause once again and hand control back "
661- "to the event loop. Eventually, enough time will have elapsed, and "
662- "``_sleep_watcher(...)`` will mark the future as done, and then itself finish "
663- "too by breaking out of the infinite ``while`` loop. Given this helper task "
664- "is only invoked once per cycle of the event loop, you'd be correct to note "
665- "that this asynchronous sleep will sleep *at least* three seconds, rather "
666- "than exactly three seconds. Note this is also of true of ``asyncio.sleep``."
661+ "to the event loop. Once enough time has elapsed, ``_sleep_watcher(...)`` "
662+ "marks the future as done and completes by exiting its infinite ``while`` "
663+ "loop. Given this helper task is only invoked once per cycle of the event "
664+ "loop, you'd be correct to note that this asynchronous sleep will sleep *at "
665+ "least* three seconds, rather than exactly three seconds. Note this is also "
666+ "true of ``asyncio.sleep``."
667667msgstr ""
668668
669669msgid ""
@@ -712,7 +712,7 @@ msgid ""
712712msgstr ""
713713
714714msgid ""
715- "But, that's all for now. Hopefully you're ready to more confidently dive "
716- "into some async programming or check out advanced topics in the :mod:`rest "
717- "of the documentation <asyncio>`."
715+ "But that's all for now. Hopefully you're ready to more confidently dive into "
716+ "some async programming or check out advanced topics in the :mod:`rest of the "
717+ "documentation <asyncio>`."
718718msgstr ""
0 commit comments