@@ -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-10-19 19:33 +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 : Bhuvansh Kataria, 2026\n "
1717"Language-Team : Panjabi (Punjabi) (https://app.transifex.com/python-doc/teams/ "
@@ -25,9 +25,6 @@ msgstr ""
2525msgid "Library and Extension FAQ"
2626msgstr ""
2727
28- msgid "Contents"
29- msgstr ""
30-
3128msgid "General Library Questions"
3229msgstr ""
3330
@@ -283,63 +280,6 @@ msgid ""
283280"the low-level primitives provided by the :mod:`_thread` module."
284281msgstr ""
285282
286- msgid "None of my threads seem to run: why?"
287- msgstr ""
288-
289- msgid ""
290- "As soon as the main thread exits, all threads are killed. Your main thread "
291- "is running too quickly, giving the threads no time to do any work."
292- msgstr ""
293-
294- msgid ""
295- "A simple fix is to add a sleep to the end of the program that's long enough "
296- "for all the threads to finish::"
297- msgstr ""
298-
299- msgid ""
300- "import threading, time\n"
301- "\n"
302- "def thread_task(name, n):\n"
303- " for i in range(n):\n"
304- " print(name, i)\n"
305- "\n"
306- "for i in range(10):\n"
307- " T = threading.Thread(target=thread_task, args=(str(i), i))\n"
308- " T.start()\n"
309- "\n"
310- "time.sleep(10) # <---------------------------!"
311- msgstr ""
312-
313- msgid ""
314- "But now (on many platforms) the threads don't run in parallel, but appear to "
315- "run sequentially, one at a time! The reason is that the OS thread scheduler "
316- "doesn't start a new thread until the previous thread is blocked."
317- msgstr ""
318-
319- msgid "A simple fix is to add a tiny sleep to the start of the run function::"
320- msgstr ""
321-
322- msgid ""
323- "def thread_task(name, n):\n"
324- " time.sleep(0.001) # <--------------------!\n"
325- " for i in range(n):\n"
326- " print(name, i)\n"
327- "\n"
328- "for i in range(10):\n"
329- " T = threading.Thread(target=thread_task, args=(str(i), i))\n"
330- " T.start()\n"
331- "\n"
332- "time.sleep(10)"
333- msgstr ""
334-
335- msgid ""
336- "Instead of trying to guess a good delay value for :func:`time.sleep`, it's "
337- "better to use some kind of semaphore mechanism. One idea is to use "
338- "the :mod:`queue` module to create a queue object, let each thread append a "
339- "token to the queue when it finishes, and let the main thread read as many "
340- "tokens from the queue as there are threads."
341- msgstr ""
342-
343283msgid "How do I parcel out work among a bunch of worker threads?"
344284msgstr ""
345285
@@ -488,38 +428,21 @@ msgid ""
488428msgstr ""
489429
490430msgid ""
491- "With the approval of :pep:`703` work is now underway to remove the GIL from "
492- "the CPython implementation of Python. Initially it will be implemented as "
493- "an optional compiler flag when building the interpreter, and so separate "
494- "builds will be available with and without the GIL. Long-term, the hope is "
495- "to settle on a single build, once the performance implications of removing "
496- "the GIL are fully understood. Python 3.13 is likely to be the first release "
497- "containing this work, although it may not be completely functional in this "
498- "release."
499- msgstr ""
500-
501- msgid ""
502- "The current work to remove the GIL is based on a `fork of Python 3.9 with "
503- "the GIL removed <https://github.com/colesbury/nogil>`_ by Sam Gross. Prior "
504- "to that, in the days of Python 1.5, Greg Stein actually implemented a "
505- "comprehensive patch set (the \" free threading\" patches) that removed the "
506- "GIL and replaced it with fine-grained locking. Adam Olsen did a similar "
507- "experiment in his `python-safethread <https://code.google.com/archive/p/"
508- "python-safethread>`_ project. Unfortunately, both of these earlier "
509- "experiments exhibited a sharp drop in single-thread performance (at least "
510- "30% slower), due to the amount of fine-grained locking necessary to "
511- "compensate for the removal of the GIL. The Python 3.9 fork is the first "
512- "attempt at removing the GIL with an acceptable performance impact."
431+ "Since Python 3.13, CPython provides an optional free-threaded build that can "
432+ "run with the GIL disabled, allowing Python threads to run in parallel on "
433+ "multiple CPU cores (see :pep:`703`). Free-threaded Python is officially "
434+ "supported as of Python 3.14 (see :pep:`779`), but is not the default build. "
435+ "See :doc:`/howto/free-threading-python` for details."
513436msgstr ""
514437
515438msgid ""
516439"The presence of the GIL in current Python releases doesn't mean that you "
517440"can't make good use of Python on multi-CPU machines! You just have to be "
518441"creative with dividing the work up between multiple *processes* rather than "
519442"multiple *threads*. The :class:`~concurrent.futures.ProcessPoolExecutor` "
520- "class in the new :mod:`concurrent.futures` module provides an easy way of "
521- "doing so; the :mod:`multiprocessing` module provides a lower-level API in "
522- "case you want more control over dispatching of tasks."
443+ "class in the :mod:`concurrent.futures` module provides an easy way of doing "
444+ "so; the :mod:`multiprocessing` module provides a lower-level API in case you "
445+ "want more control over dispatching of tasks."
523446msgstr ""
524447
525448msgid ""
@@ -534,7 +457,9 @@ msgid ""
534457"An alternative approach to reducing the impact of the GIL is to make the GIL "
535458"a per-interpreter-state lock rather than truly global. This was :ref:`first "
536459"implemented in Python 3.12 <whatsnew312-pep684>` and is available in the C "
537- "API. A Python interface to it is expected in Python 3.13. The main "
460+ "API. Python interfaces were added in Python 3.14 through "
461+ "the :mod:`concurrent.interpreters` module and "
462+ "the :class:`~concurrent.futures.InterpreterPoolExecutor` class. The main "
538463"limitation to it at the moment is likely to be 3rd party extension modules, "
539464"since these must be written with multiple interpreters in mind in order to "
540465"be usable, so many older extension modules will not be usable."
0 commit comments