@@ -11,7 +11,7 @@ msgid ""
1111msgstr ""
1212"Project-Id-Version : Python 3.10\n "
1313"Report-Msgid-Bugs-To : \n "
14- "POT-Creation-Date : 2023-08-04 15:17 +0000\n "
14+ "POT-Creation-Date : 2023-08-11 15:16 +0000\n "
1515"PO-Revision-Date : 2022-11-05 17:21+0000\n "
1616"Last-Translator : Rafael Fontenelle <rffontenelle@gmail.com>, 2022\n "
1717"Language-Team : Polish (https://app.transifex.com/python-doc/teams/5390/pl/)\n "
@@ -299,94 +299,70 @@ msgstr "Liczby odniesień"
299299
300300msgid ""
301301"The reference count is important because today's computers have a finite "
302- "(and often severely limited) memory size; it counts how many different "
303- "places there are that have a reference to an object. Such a place could be "
304- "another object, or a global (or static) C variable, or a local variable in "
305- "some C function. When an object's reference count becomes zero, the object "
306- "is deallocated. If it contains references to other objects, their "
307- "reference count is decremented. Those other objects may be deallocated in "
308- "turn, if this decrement makes their reference count become zero, and so on. "
309- "(There's an obvious problem with objects that reference each other here; "
310- "for now, the solution is \" don't do that.\" )"
311- msgstr ""
312- "Liczba odniesień jest istotna, gdyż dzisiejsze komputery mają skończony (i "
313- "zwykle poważnie ograniczony) rozmiar pamięci; liczy ona jak wiele różnych "
314- "miejsc istnieje, które przechowują odniesienie do przedmiotu. Takie miejsce "
315- "może być innym przedmiotem, zmienną C nadrzędnego poziomu (lub statyczną), "
316- "lub lokalną zmienną w jakimś zadaniu języka C. Gdy liczba odniesień do "
317- "przedmiotu staje się równa zero, przedmiot jest zdejmowany z pamięci. Jeśli "
318- "zawiera odniesienia do innych przedmiotów liczba odniesień do nich jest "
319- "obniżana po jednym dla każdego. Te inne przedmioty mogą być zdejmowane z "
320- "pamięci w konsekwencji, jeśli obniżenie liczby odniesień do nich spowoduje "
321- "że liczba odniesień stanie się równa zero, itd. (Istnieje dość oczywisty "
322- "problem z przedmiotami które wzajemnie się odnoszą do siebie; na razie "
323- "rozwiązaniem jest \" proszę tak nie robić.\" )"
324-
325- msgid ""
326- "Reference counts are always manipulated explicitly. The normal way is to "
327- "use the macro :c:func:`Py_INCREF` to increment an object's reference count "
328- "by one, and :c:func:`Py_DECREF` to decrement it by one. The :c:func:"
302+ "(and often severely limited) memory size; it counts how many different "
303+ "places there are that have a :term:`strong reference` to an object. Such a "
304+ "place could be another object, or a global (or static) C variable, or a "
305+ "local variable in some C function. When the last :term:`strong reference` to "
306+ "an object is released (i.e. its reference count becomes zero), the object is "
307+ "deallocated. If it contains references to other objects, those references "
308+ "are released. Those other objects may be deallocated in turn, if there are "
309+ "no more references to them, and so on. (There's an obvious problem with "
310+ "objects that reference each other here; for now, the solution is \" don't do "
311+ "that.\" )"
312+ msgstr ""
313+
314+ msgid ""
315+ "Reference counts are always manipulated explicitly. The normal way is to "
316+ "use the macro :c:func:`Py_INCREF` to take a new reference to an object (i.e. "
317+ "increment its reference count by one), and :c:func:`Py_DECREF` to release "
318+ "that reference (i.e. decrement the reference count by one). The :c:func:"
329319"`Py_DECREF` macro is considerably more complex than the incref one, since it "
330320"must check whether the reference count becomes zero and then cause the "
331- "object's deallocator to be called. The deallocator is a function pointer "
321+ "object's deallocator to be called. The deallocator is a function pointer "
332322"contained in the object's type structure. The type-specific deallocator "
333- "takes care of decrementing the reference counts for other objects contained "
334- "in the object if this is a compound object type, such as a list, as well as "
335- "performing any additional finalization that's needed. There's no chance "
336- "that the reference count can overflow; at least as many bits are used to "
337- "hold the reference count as there are distinct memory locations in virtual "
338- "memory (assuming ``sizeof(Py_ssize_t) >= sizeof(void*)``). Thus, the "
339- "reference count increment is a simple operation."
340- msgstr ""
341-
342- msgid ""
343- "It is not necessary to increment an object's reference count for every "
344- "local variable that contains a pointer to an object. In theory, the "
345- "object's reference count goes up by one when the variable is made to point "
346- "to it and it goes down by one when the variable goes out of scope. "
347- "However, these two cancel each other out, so at the end the reference count "
348- "hasn't changed. The only real reason to use the reference count is to "
349- "prevent the object from being deallocated as long as our variable is "
350- "pointing to it. If we know that there is at least one other reference to "
351- "the object that lives at least as long as our variable, there is no need to "
352- "increment the reference count temporarily. An important situation where "
353- "this arises is in objects that are passed as arguments to C functions in an "
354- "extension module that are called from Python; the call mechanism guarantees "
355- "to hold a reference to every argument for the duration of the call."
356- msgstr ""
357- "Nie jest konieczne zwiększanie zwiększanie liczby odniesień do przedmiotu "
358- "dla każdej lokalnej zmiennej która zawiera wskaźnik na przedmiot. "
359- "Teoretycznie, liczba odniesień do przedmiotu zwiększa się o jeden gdy "
360- "zmienna jest zmuszana do wskazywania nań i jest zmniejszana o jeden gdy "
361- "zmienna wychodzi z widoku. Jednakże te dwa działania wykluczają się "
362- "nawzajem, więc ostatecznie liczba odniesień nie ulega zmianie. Jedynym "
363- "prawdziwym powodem użycia liczby odniesień jest aby uniemożliwić zdjęcie z "
364- "pamięci przedmiotu tak długo jak nasza zmienna nań wskazuje. Jeśli wiemy, że "
365- "istnieje przynajmniej jedno inne odniesienie do przedmiotu, które żyje tak "
366- "długo jak nasza zmienna, nie ma potrzeby zwiększania liczby odniesień "
367- "tymczasowo. Istotną sytuacją gdzie to się pojawia jest w obiektach które są "
368- "przekazywane jako parametry do zadań C w modułach rozszerzających które są "
369- "wywoływane przez polecenia języka pytonowskiego; mechanizm wywołania "
370- "gwarantuje przytrzymanie odniesienia do każdego parametru na czas wywołania "
371- "zadania z tym parametrem."
323+ "takes care of releasing references for other objects contained in the object "
324+ "if this is a compound object type, such as a list, as well as performing any "
325+ "additional finalization that's needed. There's no chance that the reference "
326+ "count can overflow; at least as many bits are used to hold the reference "
327+ "count as there are distinct memory locations in virtual memory (assuming "
328+ "``sizeof(Py_ssize_t) >= sizeof(void*)``). Thus, the reference count "
329+ "increment is a simple operation."
330+ msgstr ""
331+
332+ msgid ""
333+ "It is not necessary to hold a :term:`strong reference` (i.e. increment the "
334+ "reference count) for every local variable that contains a pointer to an "
335+ "object. In theory, the object's reference count goes up by one when the "
336+ "variable is made to point to it and it goes down by one when the variable "
337+ "goes out of scope. However, these two cancel each other out, so at the end "
338+ "the reference count hasn't changed. The only real reason to use the "
339+ "reference count is to prevent the object from being deallocated as long as "
340+ "our variable is pointing to it. If we know that there is at least one "
341+ "other reference to the object that lives at least as long as our variable, "
342+ "there is no need to take a new :term:`strong reference` (i.e. increment the "
343+ "reference count) temporarily. An important situation where this arises is in "
344+ "objects that are passed as arguments to C functions in an extension module "
345+ "that are called from Python; the call mechanism guarantees to hold a "
346+ "reference to every argument for the duration of the call."
347+ msgstr ""
372348
373349msgid ""
374350"However, a common pitfall is to extract an object from a list and hold on to "
375- "it for a while without incrementing its reference count. Some other "
376- "operation might conceivably remove the object from the list, decrementing "
377- "its reference count and possibly deallocating it. The real danger is that "
378- "innocent-looking operations may invoke arbitrary Python code which could do "
379- "this; there is a code path which allows control to flow back to the user "
380- "from a :c:func: `Py_DECREF`, so almost any operation is potentially dangerous."
351+ "it for a while without taking a new reference. Some other operation might "
352+ "conceivably remove the object from the list, releasing that reference, and "
353+ "possibly deallocating it. The real danger is that innocent-looking "
354+ "operations may invoke arbitrary Python code which could do this; there is a "
355+ "code path which allows control to flow back to the user from a :c:func: "
356+ "`Py_DECREF`, so almost any operation is potentially dangerous."
381357msgstr ""
382358
383359msgid ""
384360"A safe approach is to always use the generic operations (functions whose "
385361"name begins with ``PyObject_``, ``PyNumber_``, ``PySequence_`` or "
386- "``PyMapping_``). These operations always increment the reference count of "
387- "the object they return. This leaves the caller with the responsibility to "
388- "call :c:func:`Py_DECREF` when they are done with the result; this soon "
389- "becomes second nature."
362+ "``PyMapping_``). These operations always create a new :term:`strong "
363+ "reference` (i.e. increment the reference count) of the object they return. "
364+ "This leaves the caller with the responsibility to call :c:func:`Py_DECREF` "
365+ "when they are done with the result; this soon becomes second nature."
390366msgstr ""
391367
392368msgid "Reference Count Details"
@@ -399,8 +375,8 @@ msgid ""
399375"shared). \" Owning a reference\" means being responsible for calling "
400376"Py_DECREF on it when the reference is no longer needed. Ownership can also "
401377"be transferred, meaning that the code that receives ownership of the "
402- "reference then becomes responsible for eventually decref'ing it by calling :"
403- "c: func:`Py_DECREF` or :c:func:`Py_XDECREF` when it's no longer needed---or "
378+ "reference then becomes responsible for eventually releasing it by calling :c :"
379+ "func:`Py_DECREF` or :c:func:`Py_XDECREF` when it's no longer needed---or "
404380"passing on this responsibility (usually to its caller). When a function "
405381"passes ownership of a reference on to its caller, the caller is said to "
406382"receive a *new* reference. When no ownership is transferred, the caller is "
@@ -463,8 +439,8 @@ msgid ""
463439"It is much more common to use :c:func:`PyObject_SetItem` and friends with "
464440"items whose references you are only borrowing, like arguments that were "
465441"passed in to the function you are writing. In that case, their behaviour "
466- "regarding reference counts is much saner, since you don't have to increment "
467- "a reference count so you can give a reference away (\" have it be stolen\" ). "
442+ "regarding references is much saner, since you don't have to take a new "
443+ "reference just so you can give that reference away (\" have it be stolen\" ). "
468444"For example, this function sets all items of a list (actually, any mutable "
469445"sequence) to a given item::"
470446msgstr ""
0 commit comments