@@ -11,7 +11,7 @@ msgid ""
1111msgstr ""
1212"Project-Id-Version : Python 3.15\n "
1313"Report-Msgid-Bugs-To : \n "
14- "POT-Creation-Date : 2026-11-07 18:23 +0000\n "
14+ "POT-Creation-Date : 2026-11-09 23:13 +0000\n "
1515"PO-Revision-Date : 2025-09-16 00:00+0000\n "
1616"Last-Translator : python-doc bot, 2025\n "
1717"Language-Team : Polish (https://app.transifex.com/python-doc/teams/5390/pl/)\n "
@@ -26,9 +26,6 @@ msgstr ""
2626msgid "Library and Extension FAQ"
2727msgstr ""
2828
29- msgid "Contents"
30- msgstr "Zawartość"
31-
3229msgid "General Library Questions"
3330msgstr ""
3431
@@ -292,63 +289,6 @@ msgid ""
292289"the low-level primitives provided by the :mod:`_thread` module."
293290msgstr ""
294291
295- msgid "None of my threads seem to run: why?"
296- msgstr ""
297-
298- msgid ""
299- "As soon as the main thread exits, all threads are killed. Your main thread "
300- "is running too quickly, giving the threads no time to do any work."
301- msgstr ""
302-
303- msgid ""
304- "A simple fix is to add a sleep to the end of the program that's long enough "
305- "for all the threads to finish::"
306- msgstr ""
307-
308- msgid ""
309- "import threading, time\n"
310- "\n"
311- "def thread_task(name, n):\n"
312- " for i in range(n):\n"
313- " print(name, i)\n"
314- "\n"
315- "for i in range(10):\n"
316- " T = threading.Thread(target=thread_task, args=(str(i), i))\n"
317- " T.start()\n"
318- "\n"
319- "time.sleep(10) # <---------------------------!"
320- msgstr ""
321-
322- msgid ""
323- "But now (on many platforms) the threads don't run in parallel, but appear to "
324- "run sequentially, one at a time! The reason is that the OS thread scheduler "
325- "doesn't start a new thread until the previous thread is blocked."
326- msgstr ""
327-
328- msgid "A simple fix is to add a tiny sleep to the start of the run function::"
329- msgstr ""
330-
331- msgid ""
332- "def thread_task(name, n):\n"
333- " time.sleep(0.001) # <--------------------!\n"
334- " for i in range(n):\n"
335- " print(name, i)\n"
336- "\n"
337- "for i in range(10):\n"
338- " T = threading.Thread(target=thread_task, args=(str(i), i))\n"
339- " T.start()\n"
340- "\n"
341- "time.sleep(10)"
342- msgstr ""
343-
344- msgid ""
345- "Instead of trying to guess a good delay value for :func:`time.sleep`, it's "
346- "better to use some kind of semaphore mechanism. One idea is to use "
347- "the :mod:`queue` module to create a queue object, let each thread append a "
348- "token to the queue when it finishes, and let the main thread read as many "
349- "tokens from the queue as there are threads."
350- msgstr ""
351-
352292msgid "How do I parcel out work among a bunch of worker threads?"
353293msgstr ""
354294
@@ -497,38 +437,21 @@ msgid ""
497437msgstr ""
498438
499439msgid ""
500- "With the approval of :pep:`703` work is now underway to remove the GIL from "
501- "the CPython implementation of Python. Initially it will be implemented as "
502- "an optional compiler flag when building the interpreter, and so separate "
503- "builds will be available with and without the GIL. Long-term, the hope is "
504- "to settle on a single build, once the performance implications of removing "
505- "the GIL are fully understood. Python 3.13 is likely to be the first release "
506- "containing this work, although it may not be completely functional in this "
507- "release."
508- msgstr ""
509-
510- msgid ""
511- "The current work to remove the GIL is based on a `fork of Python 3.9 with "
512- "the GIL removed <https://github.com/colesbury/nogil>`_ by Sam Gross. Prior "
513- "to that, in the days of Python 1.5, Greg Stein actually implemented a "
514- "comprehensive patch set (the \" free threading\" patches) that removed the "
515- "GIL and replaced it with fine-grained locking. Adam Olsen did a similar "
516- "experiment in his `python-safethread <https://code.google.com/archive/p/"
517- "python-safethread>`_ project. Unfortunately, both of these earlier "
518- "experiments exhibited a sharp drop in single-thread performance (at least "
519- "30% slower), due to the amount of fine-grained locking necessary to "
520- "compensate for the removal of the GIL. The Python 3.9 fork is the first "
521- "attempt at removing the GIL with an acceptable performance impact."
440+ "Since Python 3.13, CPython provides an optional free-threaded build that can "
441+ "run with the GIL disabled, allowing Python threads to run in parallel on "
442+ "multiple CPU cores (see :pep:`703`). Free-threaded Python is officially "
443+ "supported as of Python 3.14 (see :pep:`779`), but is not the default build. "
444+ "See :doc:`/howto/free-threading-python` for details."
522445msgstr ""
523446
524447msgid ""
525448"The presence of the GIL in current Python releases doesn't mean that you "
526449"can't make good use of Python on multi-CPU machines! You just have to be "
527450"creative with dividing the work up between multiple *processes* rather than "
528451"multiple *threads*. The :class:`~concurrent.futures.ProcessPoolExecutor` "
529- "class in the new :mod:`concurrent.futures` module provides an easy way of "
530- "doing so; the :mod:`multiprocessing` module provides a lower-level API in "
531- "case you want more control over dispatching of tasks."
452+ "class in the :mod:`concurrent.futures` module provides an easy way of doing "
453+ "so; the :mod:`multiprocessing` module provides a lower-level API in case you "
454+ "want more control over dispatching of tasks."
532455msgstr ""
533456
534457msgid ""
@@ -543,7 +466,9 @@ msgid ""
543466"An alternative approach to reducing the impact of the GIL is to make the GIL "
544467"a per-interpreter-state lock rather than truly global. This was :ref:`first "
545468"implemented in Python 3.12 <whatsnew312-pep684>` and is available in the C "
546- "API. A Python interface to it is expected in Python 3.13. The main "
469+ "API. Python interfaces were added in Python 3.14 through "
470+ "the :mod:`concurrent.interpreters` module and "
471+ "the :class:`~concurrent.futures.InterpreterPoolExecutor` class. The main "
547472"limitation to it at the moment is likely to be 3rd party extension modules, "
548473"since these must be written with multiple interpreters in mind in order to "
549474"be usable, so many older extension modules will not be usable."
0 commit comments