@@ -13,7 +13,7 @@ msgid ""
1313msgstr ""
1414"Project-Id-Version : Python 3.12\n "
1515"Report-Msgid-Bugs-To : \n "
16- "POT-Creation-Date : 2023-07-28 14:13+0000\n "
16+ "POT-Creation-Date : 2023-08-11 14:13+0000\n "
1717"PO-Revision-Date : 2021-06-28 00:49+0000\n "
1818"
Last-Translator :
Maciej Olko <[email protected] >, 2023\n "
1919"Language-Team : Polish (https://app.transifex.com/python-doc/teams/5390/pl/)\n "
@@ -335,94 +335,70 @@ msgstr "Liczby odniesień"
335335
336336msgid ""
337337"The reference count is important because today's computers have a finite "
338- "(and often severely limited) memory size; it counts how many different "
339- "places there are that have a reference to an object. Such a place could be "
340- "another object, or a global (or static) C variable, or a local variable in "
341- "some C function. When an object's reference count becomes zero, the object "
342- "is deallocated. If it contains references to other objects, their "
343- "reference count is decremented. Those other objects may be deallocated in "
344- "turn, if this decrement makes their reference count become zero, and so on. "
345- "(There's an obvious problem with objects that reference each other here; "
346- "for now, the solution is \" don't do that.\" )"
347- msgstr ""
348- "Liczba odniesień jest istotna, gdyż dzisiejsze komputery mają skończony (i "
349- "zwykle poważnie ograniczony) rozmiar pamięci; liczy ona jak wiele różnych "
350- "miejsc istnieje, które przechowują odniesienie do przedmiotu. Takie miejsce "
351- "może być innym przedmiotem, zmienną C nadrzędnego poziomu (lub statyczną), "
352- "lub lokalną zmienną w jakimś zadaniu języka C. Gdy liczba odniesień do "
353- "przedmiotu staje się równa zero, przedmiot jest zdejmowany z pamięci. Jeśli "
354- "zawiera odniesienia do innych przedmiotów liczba odniesień do nich jest "
355- "obniżana po jednym dla każdego. Te inne przedmioty mogą być zdejmowane z "
356- "pamięci w konsekwencji, jeśli obniżenie liczby odniesień do nich spowoduje "
357- "że liczba odniesień stanie się równa zero, itd. (Istnieje dość oczywisty "
358- "problem z przedmiotami które wzajemnie się odnoszą do siebie; na razie "
359- "rozwiązaniem jest \" proszę tak nie robić.\" )"
360-
361- msgid ""
362- "Reference counts are always manipulated explicitly. The normal way is to "
363- "use the macro :c:func:`Py_INCREF` to increment an object's reference count "
364- "by one, and :c:func:`Py_DECREF` to decrement it by one. The :c:func:"
338+ "(and often severely limited) memory size; it counts how many different "
339+ "places there are that have a :term:`strong reference` to an object. Such a "
340+ "place could be another object, or a global (or static) C variable, or a "
341+ "local variable in some C function. When the last :term:`strong reference` to "
342+ "an object is released (i.e. its reference count becomes zero), the object is "
343+ "deallocated. If it contains references to other objects, those references "
344+ "are released. Those other objects may be deallocated in turn, if there are "
345+ "no more references to them, and so on. (There's an obvious problem with "
346+ "objects that reference each other here; for now, the solution is \" don't do "
347+ "that.\" )"
348+ msgstr ""
349+
350+ msgid ""
351+ "Reference counts are always manipulated explicitly. The normal way is to "
352+ "use the macro :c:func:`Py_INCREF` to take a new reference to an object (i.e. "
353+ "increment its reference count by one), and :c:func:`Py_DECREF` to release "
354+ "that reference (i.e. decrement the reference count by one). The :c:func:"
365355"`Py_DECREF` macro is considerably more complex than the incref one, since it "
366356"must check whether the reference count becomes zero and then cause the "
367- "object's deallocator to be called. The deallocator is a function pointer "
357+ "object's deallocator to be called. The deallocator is a function pointer "
368358"contained in the object's type structure. The type-specific deallocator "
369- "takes care of decrementing the reference counts for other objects contained "
370- "in the object if this is a compound object type, such as a list, as well as "
371- "performing any additional finalization that's needed. There's no chance "
372- "that the reference count can overflow; at least as many bits are used to "
373- "hold the reference count as there are distinct memory locations in virtual "
374- "memory (assuming ``sizeof(Py_ssize_t) >= sizeof(void*)``). Thus, the "
375- "reference count increment is a simple operation."
376- msgstr ""
377-
378- msgid ""
379- "It is not necessary to increment an object's reference count for every "
380- "local variable that contains a pointer to an object. In theory, the "
381- "object's reference count goes up by one when the variable is made to point "
382- "to it and it goes down by one when the variable goes out of scope. "
383- "However, these two cancel each other out, so at the end the reference count "
384- "hasn't changed. The only real reason to use the reference count is to "
385- "prevent the object from being deallocated as long as our variable is "
386- "pointing to it. If we know that there is at least one other reference to "
387- "the object that lives at least as long as our variable, there is no need to "
388- "increment the reference count temporarily. An important situation where "
389- "this arises is in objects that are passed as arguments to C functions in an "
390- "extension module that are called from Python; the call mechanism guarantees "
391- "to hold a reference to every argument for the duration of the call."
392- msgstr ""
393- "Nie jest konieczne zwiększanie zwiększanie liczby odniesień do przedmiotu "
394- "dla każdej lokalnej zmiennej która zawiera wskaźnik na przedmiot. "
395- "Teoretycznie, liczba odniesień do przedmiotu zwiększa się o jeden gdy "
396- "zmienna jest zmuszana do wskazywania nań i jest zmniejszana o jeden gdy "
397- "zmienna wychodzi z widoku. Jednakże te dwa działania wykluczają się "
398- "nawzajem, więc ostatecznie liczba odniesień nie ulega zmianie. Jedynym "
399- "prawdziwym powodem użycia liczby odniesień jest aby uniemożliwić zdjęcie z "
400- "pamięci przedmiotu tak długo jak nasza zmienna nań wskazuje. Jeśli wiemy, że "
401- "istnieje przynajmniej jedno inne odniesienie do przedmiotu, które żyje tak "
402- "długo jak nasza zmienna, nie ma potrzeby zwiększania liczby odniesień "
403- "tymczasowo. Istotną sytuacją gdzie to się pojawia jest w obiektach które są "
404- "przekazywane jako parametry do zadań C w modułach rozszerzających które są "
405- "wywoływane przez polecenia języka pytonowskiego; mechanizm wywołania "
406- "gwarantuje przytrzymanie odniesienia do każdego parametru na czas wywołania "
407- "zadania z tym parametrem."
359+ "takes care of releasing references for other objects contained in the object "
360+ "if this is a compound object type, such as a list, as well as performing any "
361+ "additional finalization that's needed. There's no chance that the reference "
362+ "count can overflow; at least as many bits are used to hold the reference "
363+ "count as there are distinct memory locations in virtual memory (assuming "
364+ "``sizeof(Py_ssize_t) >= sizeof(void*)``). Thus, the reference count "
365+ "increment is a simple operation."
366+ msgstr ""
367+
368+ msgid ""
369+ "It is not necessary to hold a :term:`strong reference` (i.e. increment the "
370+ "reference count) for every local variable that contains a pointer to an "
371+ "object. In theory, the object's reference count goes up by one when the "
372+ "variable is made to point to it and it goes down by one when the variable "
373+ "goes out of scope. However, these two cancel each other out, so at the end "
374+ "the reference count hasn't changed. The only real reason to use the "
375+ "reference count is to prevent the object from being deallocated as long as "
376+ "our variable is pointing to it. If we know that there is at least one "
377+ "other reference to the object that lives at least as long as our variable, "
378+ "there is no need to take a new :term:`strong reference` (i.e. increment the "
379+ "reference count) temporarily. An important situation where this arises is in "
380+ "objects that are passed as arguments to C functions in an extension module "
381+ "that are called from Python; the call mechanism guarantees to hold a "
382+ "reference to every argument for the duration of the call."
383+ msgstr ""
408384
409385msgid ""
410386"However, a common pitfall is to extract an object from a list and hold on to "
411- "it for a while without incrementing its reference count. Some other "
412- "operation might conceivably remove the object from the list, decrementing "
413- "its reference count and possibly deallocating it. The real danger is that "
414- "innocent-looking operations may invoke arbitrary Python code which could do "
415- "this; there is a code path which allows control to flow back to the user "
416- "from a :c:func: `Py_DECREF`, so almost any operation is potentially dangerous."
387+ "it for a while without taking a new reference. Some other operation might "
388+ "conceivably remove the object from the list, releasing that reference, and "
389+ "possibly deallocating it. The real danger is that innocent-looking "
390+ "operations may invoke arbitrary Python code which could do this; there is a "
391+ "code path which allows control to flow back to the user from a :c:func: "
392+ "`Py_DECREF`, so almost any operation is potentially dangerous."
417393msgstr ""
418394
419395msgid ""
420396"A safe approach is to always use the generic operations (functions whose "
421397"name begins with ``PyObject_``, ``PyNumber_``, ``PySequence_`` or "
422- "``PyMapping_``). These operations always increment the reference count of "
423- "the object they return. This leaves the caller with the responsibility to "
424- "call :c:func:`Py_DECREF` when they are done with the result; this soon "
425- "becomes second nature."
398+ "``PyMapping_``). These operations always create a new :term:`strong "
399+ "reference` (i.e. increment the reference count) of the object they return. "
400+ "This leaves the caller with the responsibility to call :c:func:`Py_DECREF` "
401+ "when they are done with the result; this soon becomes second nature."
426402msgstr ""
427403
428404msgid "Reference Count Details"
@@ -435,8 +411,8 @@ msgid ""
435411"shared). \" Owning a reference\" means being responsible for calling "
436412"Py_DECREF on it when the reference is no longer needed. Ownership can also "
437413"be transferred, meaning that the code that receives ownership of the "
438- "reference then becomes responsible for eventually decref'ing it by calling :"
439- "c: func:`Py_DECREF` or :c:func:`Py_XDECREF` when it's no longer needed---or "
414+ "reference then becomes responsible for eventually releasing it by calling :c :"
415+ "func:`Py_DECREF` or :c:func:`Py_XDECREF` when it's no longer needed---or "
440416"passing on this responsibility (usually to its caller). When a function "
441417"passes ownership of a reference on to its caller, the caller is said to "
442418"receive a *new* reference. When no ownership is transferred, the caller is "
@@ -499,8 +475,8 @@ msgid ""
499475"It is much more common to use :c:func:`PyObject_SetItem` and friends with "
500476"items whose references you are only borrowing, like arguments that were "
501477"passed in to the function you are writing. In that case, their behaviour "
502- "regarding reference counts is much saner, since you don't have to increment "
503- "a reference count so you can give a reference away (\" have it be stolen\" ). "
478+ "regarding references is much saner, since you don't have to take a new "
479+ "reference just so you can give that reference away (\" have it be stolen\" ). "
504480"For example, this function sets all items of a list (actually, any mutable "
505481"sequence) to a given item::"
506482msgstr ""
0 commit comments