# SOME DESCRIPTIVE TITLE.

# Copyright (C) 2001 Python Software Foundation

# This file is distributed under the same license as the Python package.

# FIRST AUTHOR <EMAIL@ADDRESS>, YEAR.

#

# Translators:

# python-doc bot, 2026

#

#, fuzzy

msgid ""

msgstr ""

"Project-Id-Version: Python 3.15\n"

"Report-Msgid-Bugs-To: \n"

"POT-Creation-Date: 2026-05-27 16:58+0000\n"

"PO-Revision-Date: 2025-09-16 00:00+0000\n"

"Last-Translator: python-doc bot, 2026\n"

"Language-Team: Polish (https://app.transifex.com/python-doc/teams/5390/pl/)\n"

"MIME-Version: 1.0\n"

"Content-Type: text/plain; charset=UTF-8\n"

"Content-Transfer-Encoding: 8bit\n"

"Language: pl\n"

"Plural-Forms: nplurals=4; plural=(n==1 ? 0 : (n%10>=2 && n%10<=4) && "

"(n%100<12 || n%100>14) ? 1 : n!=1 && (n%10>=0 && n%10<=1) || (n%10>=5 && "

"n%10<=9) || (n%100>=12 && n%100<=14) ? 2 : 3);\n"

msgid "Using the C API: Assorted topics"

msgstr ""

msgid ""

"The :ref:`tutorial <first-extension-module>` walked you through creating a C "

"API extension module, but left many areas unexplained. This document looks "

"at several concepts that you'll need to learn in order to write more complex "

"extensions."

msgstr ""

msgid "Errors and Exceptions"

msgstr "Błędy i wyjątki"

msgid ""

"An important convention throughout the Python interpreter is the following: "

"when a function fails, it should set an exception condition and return an "

"error value (usually ``-1`` or a ``NULL`` pointer). Exception information "

"is stored in three members of the interpreter's thread state. These are "

"``NULL`` if there is no exception. Otherwise they are the C equivalents of "

"the members of the Python tuple returned by :meth:`sys.exc_info`. These are "

"the exception type, exception instance, and a traceback object. It is "

"important to know about them to understand how errors are passed around."

msgstr ""

msgid ""

"The Python API defines a number of functions to set various types of "

"exceptions."

msgstr ""

"Sprzęg języka pytonowskiego określa pewien zestaw zadań do ustawiania "

"różnych rodzajów wyjątków."

msgid ""

"The most common one is :c:func:`PyErr_SetString`. Its arguments are an "

"exception object and a C string. The exception object is usually a "

"predefined object like :c:data:`PyExc_ZeroDivisionError`. The C string "

"indicates the cause of the error and is converted to a Python string object "

"and stored as the \"associated value\" of the exception."

msgstr ""

msgid ""

"Another useful function is :c:func:`PyErr_SetFromErrno`, which only takes an "

"exception argument and constructs the associated value by inspection of the "

"global variable :c:data:`errno`. The most general function is :c:func:"

"`PyErr_SetObject`, which takes two object arguments, the exception and its "

"associated value. You don't need to :c:func:`Py_INCREF` the objects passed "

"to any of these functions."

msgstr ""

msgid ""

"You can test non-destructively whether an exception has been set with :c:"

"func:`PyErr_Occurred`. This returns the current exception object, or "

"``NULL`` if no exception has occurred. You normally don't need to call :c:"

"func:`PyErr_Occurred` to see whether an error occurred in a function call, "

"since you should be able to tell from the return value."

msgstr ""

msgid ""

"When a function *f* that calls another function *g* detects that the latter "

"fails, *f* should itself return an error value (usually ``NULL`` or "

"``-1``). It should *not* call one of the ``PyErr_*`` functions --- one has "

"already been called by *g*. *f*'s caller is then supposed to also return an "

"error indication to *its* caller, again *without* calling ``PyErr_*``, and "

"so on --- the most detailed cause of the error was already reported by the "

"function that first detected it. Once the error reaches the Python "

"interpreter's main loop, this aborts the currently executing Python code and "

"tries to find an exception handler specified by the Python programmer."

msgstr ""

msgid ""

"(There are situations where a module can actually give a more detailed error "

"message by calling another ``PyErr_*`` function, and in such cases it is "

"fine to do so. As a general rule, however, this is not necessary, and can "

"cause information about the cause of the error to be lost: most operations "

"can fail for a variety of reasons.)"

msgstr ""

msgid ""

"To ignore an exception set by a function call that failed, the exception "

"condition must be cleared explicitly by calling :c:func:`PyErr_Clear`. The "

"only time C code should call :c:func:`PyErr_Clear` is if it doesn't want to "

"pass the error on to the interpreter but wants to handle it completely by "

"itself (possibly by trying something else, or pretending nothing went wrong)."

msgstr ""

msgid ""

"Every failing :c:func:`malloc` call must be turned into an exception --- the "

"direct caller of :c:func:`malloc` (or :c:func:`realloc`) must call :c:func:"

"`PyErr_NoMemory` and return a failure indicator itself. All the object-"

"creating functions (for example, :c:func:`PyLong_FromLong`) already do this, "

"so this note is only relevant to those who call :c:func:`malloc` directly."

msgstr ""

msgid ""

"Also note that, with the important exception of :c:func:`PyArg_ParseTuple` "

"and friends, functions that return an integer status usually return a "

"positive value or zero for success and ``-1`` for failure, like Unix system "

"calls."

msgstr ""

msgid ""

"Finally, be careful to clean up garbage (by making :c:func:`Py_XDECREF` or :"

"c:func:`Py_DECREF` calls for objects you have already created) when you "

"return an error indicator!"

msgstr ""

msgid ""

"The choice of which exception to raise is entirely yours. There are "

"predeclared C objects corresponding to all built-in Python exceptions, such "

"as :c:data:`PyExc_ZeroDivisionError`, which you can use directly. Of course, "

"you should choose exceptions wisely --- don't use :c:data:`PyExc_TypeError` "

"to mean that a file couldn't be opened (that should probably be :c:data:"

"`PyExc_OSError`). If something's wrong with the argument list, the :c:func:"

"`PyArg_ParseTuple` function usually raises :c:data:`PyExc_TypeError`. If "

"you have an argument whose value must be in a particular range or must "

"satisfy other conditions, :c:data:`PyExc_ValueError` is appropriate."

msgstr ""

msgid ""

"You can also define a new exception that is unique to your module. The "

"simplest way to do this is to declare a static global object variable at the "

"beginning of the file::"

msgstr ""

msgid "static PyObject *SpamError = NULL;"

msgstr ""

msgid ""

"and initialize it by calling :c:func:`PyErr_NewException` in the module's :c:"

"data:`Py_mod_exec` function (:c:func:`!spam_module_exec`)::"

msgstr ""

msgid "SpamError = PyErr_NewException(\"spam.error\", NULL, NULL);"

msgstr ""

msgid ""

"Since :c:data:`!SpamError` is a global variable, it will be overwritten "

"every time the module is reinitialized, when the :c:data:`Py_mod_exec` "

"function is called."

msgstr ""

msgid ""

"For now, let's avoid the issue: we will block repeated initialization by "

"raising an :py:exc:`ImportError`::"

msgstr ""

msgid ""

"static PyObject *SpamError = NULL;\n"

"\n"

"static int\n"

"spam_module_exec(PyObject *m)\n"

"{\n"

" if (SpamError != NULL) {\n"

" PyErr_SetString(PyExc_ImportError,\n"

" \"cannot initialize spam module more than once\");\n"

" return -1;\n"

" }\n"

" SpamError = PyErr_NewException(\"spam.error\", NULL, NULL);\n"

" if (PyModule_AddObjectRef(m, \"SpamError\", SpamError) < 0) {\n"

" return -1;\n"

" }\n"

"\n"

" return 0;\n"

"}\n"

"\n"

"static PyModuleDef_Slot spam_module_slots[] = {\n"

" {Py_mod_exec, spam_module_exec},\n"

" {0, NULL}\n"

"};\n"

"\n"

"static struct PyModuleDef spam_module = {\n"

" .m_base = PyModuleDef_HEAD_INIT,\n"

" .m_name = \"spam\",\n"

" .m_size = 0, // non-negative\n"

" .m_slots = spam_module_slots,\n"

"};\n"

"\n"

"PyMODINIT_FUNC\n"

"PyInit_spam(void)\n"

"{\n"

" return PyModuleDef_Init(&spam_module);\n"

"}"

msgstr ""

msgid ""

"Note that the Python name for the exception object is :exc:`!spam.error`. "

"The :c:func:`PyErr_NewException` function may create a class with the base "

"class being :exc:`Exception` (unless another class is passed in instead of "

"``NULL``), described in :ref:`bltin-exceptions`."

msgstr ""

msgid ""

"Note also that the :c:data:`!SpamError` variable retains a reference to the "

"newly created exception class; this is intentional! Since the exception "

"could be removed from the module by external code, an owned reference to the "

"class is needed to ensure that it will not be discarded, causing :c:data:`!"

"SpamError` to become a dangling pointer. Should it become a dangling "

"pointer, C code which raises the exception could cause a core dump or other "

"unintended side effects."

msgstr ""

msgid ""

"For now, the :c:func:`Py_DECREF` call to remove this reference is missing. "

"Even when the Python interpreter shuts down, the global :c:data:`!SpamError` "

"variable will not be garbage-collected. It will \"leak\". We did, however, "

"ensure that this will happen at most once per process."

msgstr ""

msgid ""

"We discuss the use of :c:macro:`PyMODINIT_FUNC` as a function return type "

"later in this sample."

msgstr ""

msgid ""

"The :exc:`!spam.error` exception can be raised in your extension module "

"using a call to :c:func:`PyErr_SetString` as shown below::"

msgstr ""

msgid ""

"static PyObject *\n"

"spam_system(PyObject *self, PyObject *args)\n"

"{\n"

" const char *command;\n"

" int sts;\n"

"\n"

" if (!PyArg_ParseTuple(args, \"s\", &command))\n"

" return NULL;\n"

" sts = system(command);\n"

" if (sts < 0) {\n"

" PyErr_SetString(SpamError, \"System command failed\");\n"

" return NULL;\n"

" }\n"

" return PyLong_FromLong(sts);\n"

"}"

msgstr ""

msgid "Embedding an extension"

msgstr ""

msgid ""

"If you want to make your module a permanent part of the Python interpreter, "

"you will have to change the configuration setup and rebuild the "

"interpreter. On Unix, place your file (:file:`spammodule.c` for example) in "

"the :file:`Modules/` directory of an unpacked source distribution, add a "

"line to the file :file:`Modules/Setup.local` describing your file:"

msgstr ""

msgid "spam spammodule.o"

msgstr ""

msgid ""

"and rebuild the interpreter by running :program:`make` in the toplevel "

"directory. You can also run :program:`make` in the :file:`Modules/` "

"subdirectory, but then you must first rebuild :file:`Makefile` there by "

"running ':program:`make` Makefile'. (This is necessary each time you change "

"the :file:`Setup` file.)"

msgstr ""

"i przebuduj program interpretujący przez uruchomienie programu :program:"

"`make` w katalogu głównym instalacji. Możesz także uruchomić program :"

"program:`make` w podkatalogu :file:`Modules/`, ale wtedy musisz najpierw "

"przebudować plik :file:`Makefile` tam przez uruchomienie programu :program:"

"`make` Makefile'. To jest konieczne za każdym razem gdy zmieniasz plik :file:"

"`Setup`.)"

msgid ""

"If your module requires additional libraries to link with, these can be "

"listed on the line in the configuration file as well, for instance:"

msgstr ""

msgid "spam spammodule.o -lX11"

msgstr ""

msgid "Calling Python Functions from C"

msgstr "Wywoływanie zadań języka pytonowskiego z C"

msgid ""

"The tutorial concentrated on making C functions callable from Python. The "

"reverse is also useful: calling Python functions from C. This is especially "

"the case for libraries that support so-called \"callback\" functions. If a "

"C interface makes use of callbacks, the equivalent Python often needs to "

"provide a callback mechanism to the Python programmer; the implementation "

"will require calling the Python callback functions from a C callback. Other "

"uses are also imaginable."

msgstr ""

msgid ""

"Fortunately, the Python interpreter is easily called recursively, and there "

"is a standard interface to call a Python function. (I won't dwell on how to "

"call the Python parser with a particular string as input --- if you're "

"interested, have a look at the implementation of the :option:`-c` command "

"line option in :file:`Modules/main.c` from the Python source code.)"

msgstr ""

"Szczęśliwie, program interpretujący polecenia języka pytonowskiego jest "

"łatwo wywoływany rekursywnie i istnieje standardowy sprzęg aby wywołać "

"zadanie języka pytonowskiego. (Nie będę rozpisywał się o tym jak wywołać "

"czytnik języka pytonowskiego z konkretnym ciągiem znaków na wejściu --- "

"jeśli jesteś zainteresowany, spójrz na wypełnienie opcji :option:`-c` "

"wiersza polecenia w :file:`Modules/main.c` z kodu źródłowego języka "

"pytonowskiego.)"

msgid ""

"Calling a Python function is easy. First, the Python program must somehow "

"pass you the Python function object. You should provide a function (or some "

"other interface) to do this. When this function is called, save a pointer "

"to the Python function object (be careful to :c:func:`Py_INCREF` it!) in a "

"global variable --- or wherever you see fit. For example, the following "

"function might be part of a module definition::"

msgstr ""

msgid ""

"static PyObject *my_callback = NULL;\n"

"\n"

"static PyObject *\n"

"my_set_callback(PyObject *dummy, PyObject *args)\n"

"{\n"

" PyObject *result = NULL;\n"

" PyObject *temp;\n"

"\n"

" if (PyArg_ParseTuple(args, \"O:set_callback\", &temp)) {\n"

" if (!PyCallable_Check(temp)) {\n"

" PyErr_SetString(PyExc_TypeError, \"parameter must be "

"callable\");\n"

" return NULL;\n"

" }\n"

" Py_XINCREF(temp); /* Add a reference to new callback */\n"

" Py_XDECREF(my_callback); /* Dispose of previous callback */\n"

" my_callback = temp; /* Remember new callback */\n"

" /* Boilerplate to return \"None\" */\n"

" Py_INCREF(Py_None);\n"

" result = Py_None;\n"

" }\n"

" return result;\n"

"}"

msgstr ""

msgid ""

"This function must be registered with the interpreter using the :c:macro:"

"`METH_VARARGS` flag in :c:type:`PyMethodDef.ml_flags`. The :c:func:"

"`PyArg_ParseTuple` function and its arguments are documented in section :ref:"

"`parsetuple`."

msgstr ""

msgid ""

"The macros :c:func:`Py_XINCREF` and :c:func:`Py_XDECREF` increment/decrement "

"the reference count of an object and are safe in the presence of ``NULL`` "

"pointers (but note that *temp* will not be ``NULL`` in this context). More "

"info on them in section :ref:`refcounts`."

msgstr ""

msgid ""

"Later, when it is time to call the function, you call the C function :c:func:"

"`PyObject_CallObject`. This function has two arguments, both pointers to "

"arbitrary Python objects: the Python function, and the argument list. The "

"argument list must always be a tuple object, whose length is the number of "

"arguments. To call the Python function with no arguments, pass in ``NULL``, "

"or an empty tuple; to call it with one argument, pass a singleton tuple. :c:"

"func:`Py_BuildValue` returns a tuple when its format string consists of zero "

"or more format codes between parentheses. For example::"

msgstr ""

msgid ""

"int arg;\n"

"PyObject *arglist;\n"

"PyObject *result;\n"

"...\n"

"arg = 123;\n"

"...\n"

"/* Time to call the callback */\n"

"arglist = Py_BuildValue(\"(i)\", arg);\n"

"result = PyObject_CallObject(my_callback, arglist);\n"

"Py_DECREF(arglist);"

msgstr ""

msgid ""

":c:func:`PyObject_CallObject` returns a Python object pointer: this is the "

"return value of the Python function. :c:func:`PyObject_CallObject` is "

"\"reference-count-neutral\" with respect to its arguments. In the example a "

"new tuple was created to serve as the argument list, which is :c:func:"

"`Py_DECREF`\\ -ed immediately after the :c:func:`PyObject_CallObject` call."

msgstr ""

msgid ""

"The return value of :c:func:`PyObject_CallObject` is \"new\": either it is a "

"brand new object, or it is an existing object whose reference count has been "

"incremented. So, unless you want to save it in a global variable, you "

"should somehow :c:func:`Py_DECREF` the result, even (especially!) if you are "

"not interested in its value."

msgstr ""

msgid ""

"Before you do this, however, it is important to check that the return value "

"isn't ``NULL``. If it is, the Python function terminated by raising an "

"exception. If the C code that called :c:func:`PyObject_CallObject` is called "

"from Python, it should now return an error indication to its Python caller, "

"so the interpreter can print a stack trace, or the calling Python code can "

"handle the exception. If this is not possible or desirable, the exception "

"should be cleared by calling :c:func:`PyErr_Clear`. For example::"

msgstr ""

msgid ""

"if (result == NULL)\n"

" return NULL; /* Pass error back */\n"

"...use result...\n"

"Py_DECREF(result);"

msgstr ""

msgid ""

"Depending on the desired interface to the Python callback function, you may "

"also have to provide an argument list to :c:func:`PyObject_CallObject`. In "

"some cases the argument list is also provided by the Python program, through "

"the same interface that specified the callback function. It can then be "

"saved and used in the same manner as the function object. In other cases, "

"you may have to construct a new tuple to pass as the argument list. The "

"simplest way to do this is to call :c:func:`Py_BuildValue`. For example, if "

"you want to pass an integral event code, you might use the following code::"

msgstr ""

msgid ""

"PyObject *arglist;\n"

"...\n"

"arglist = Py_BuildValue(\"(l)\", eventcode);\n"

"result = PyObject_CallObject(my_callback, arglist);\n"

"Py_DECREF(arglist);\n"

"if (result == NULL)\n"

" return NULL; /* Pass error back */\n"

"/* Here maybe use the result */\n"

"Py_DECREF(result);"

msgstr ""

msgid ""

"Note the placement of ``Py_DECREF(arglist)`` immediately after the call, "

"before the error check! Also note that strictly speaking this code is not "

"complete: :c:func:`Py_BuildValue` may run out of memory, and this should be "

"checked."

msgstr ""

msgid ""

"You may also call a function with keyword arguments by using :c:func:"

"`PyObject_Call`, which supports arguments and keyword arguments. As in the "

"above example, we use :c:func:`Py_BuildValue` to construct the dictionary. ::"

msgstr ""

msgid ""

"PyObject *dict;\n"

"...\n"

"dict = Py_BuildValue(\"{s:i}\", \"name\", val);\n"

"result = PyObject_Call(my_callback, NULL, dict);\n"

"Py_DECREF(dict);\n"

"if (result == NULL)\n"

" return NULL; /* Pass error back */\n"

"/* Here maybe use the result */\n"

"Py_DECREF(result);"

msgstr ""

msgid "Extracting Parameters in Extension Functions"

msgstr "Wydobywanie parametrów w zadaniach rozszerzających"

msgid ""

"The :ref:`tutorial <first-extension-module>` uses a \":c:data:`METH_O`\" "

"function, which is limited to a single Python argument. If you want more, "

"you can use :c:data:`METH_VARARGS` instead. With this flag, the C function "

"will receive a :py:class:`tuple` of arguments instead of a single object."

msgstr ""

msgid ""

"For unpacking the tuple, CPython provides the :c:func:`PyArg_ParseTuple` "

"function, declared as follows::"

msgstr ""

msgid "int PyArg_ParseTuple(PyObject *arg, const char *format, ...);"

msgstr ""

msgid ""

"The *arg* argument must be a tuple object containing an argument list passed "

"from Python to a C function. The *format* argument must be a format string, "

"whose syntax is explained in :ref:`arg-parsing` in the Python/C API "

"Reference Manual. The remaining arguments must be addresses of variables "

"whose type is determined by the format string."

msgstr ""

"Parametr *arg* musi być przedmiotem - krotką zawierającym listę parametrów z "

"języka pytonowskiego dla zadania C. Parametr *format* musi być ciągiem "

"formatu, którego składnia jest wyjaśniona w :ref:`arg-parsing` w podręczniku "

"użytkownika API Python/C. Pozostałe parametry muszą być adresami zmiennych "

"których rodzaj jest określony przez ciąg formatujący."

msgid ""

"For example, to receive a single Python :py:class:`str` object and turn it "

"into a C buffer, you would use ``\"s\"`` as the format string::"

msgstr ""

msgid ""

"const char *command;\n"

"if (!PyArg_ParseTuple(args, \"s\", &command)) {\n"

" return NULL;\n"

"}"

msgstr ""

msgid ""

"If an error is detected in the argument list, :c:func:`!PyArg_ParseTuple` "

"returns ``NULL`` (the error indicator for functions returning object "

"pointers); your function may return ``NULL``, relying on the exception set "

"by :c:func:`PyArg_ParseTuple`."

msgstr ""

msgid ""

"Note that while :c:func:`PyArg_ParseTuple` checks that the Python arguments "

"have the required types, it cannot check the validity of the addresses of C "

"variables passed to the call: if you make mistakes there, your code will "

"probably crash or at least overwrite random bits in memory. So be careful!"

msgstr ""

msgid ""

"Note that any Python object references which are provided to the caller are "

"*borrowed* references; do not decrement their reference count!"

msgstr ""

"Zauważ, że dowolne odniesienia do przedmiotów języka pytonowskiego, które są "

"dostarczone wołającemu są *pożyczonymi* odniesieniami; nie zmniejszaj liczby "

"tych odniesień."

msgid "Some example calls::"

msgstr "Pewne przykładowe wywołania::"

msgid "#include <Python.h>"

msgstr ""

msgid ""

"int ok;\n"

"int i, j;\n"

"long k, l;\n"

"const char *s;\n"

"Py_ssize_t size;\n"

"\n"

"ok = PyArg_ParseTuple(args, \"\"); /* No arguments */\n"

" /* Python call: f() */"

msgstr ""

msgid ""

"ok = PyArg_ParseTuple(args, \"s\", &s); /* A string */\n"

" /* Possible Python call: f('whoops!') */"

msgstr ""

msgid ""

"ok = PyArg_ParseTuple(args, \"lls\", &k, &l, &s); /* Two longs and a string "

"*/\n"

" /* Possible Python call: f(1, 2, 'three') */"

msgstr ""

msgid ""

"ok = PyArg_ParseTuple(args, \"(ii)s#\", &i, &j, &s, &size);\n"

" /* A pair of ints and a string, whose size is also returned */\n"

" /* Possible Python call: f((1, 2), 'three') */"

msgstr ""

msgid ""

"{\n"

" const char *file;\n"

" const char *mode = \"r\";\n"

" int bufsize = 0;\n"

" ok = PyArg_ParseTuple(args, \"s|si\", &file, &mode, &bufsize);\n"

" /* A string, and optionally another string and an integer */\n"

" /* Possible Python calls:\n"

" f('spam')\n"

" f('spam', 'w')\n"

" f('spam', 'wb', 100000) */\n"

"}"

msgstr ""

msgid ""

"{\n"

" int left, top, right, bottom, h, v;\n"

" ok = PyArg_ParseTuple(args, \"((ii)(ii))(ii)\",\n"

" &left, &top, &right, &bottom, &h, &v);\n"

" /* A rectangle and a point */\n"

" /* Possible Python call:\n"

" f(((0, 0), (400, 300)), (10, 10)) */\n"

"}"

msgstr ""

msgid ""

"{\n"

" Py_complex c;\n"

" ok = PyArg_ParseTuple(args, \"D:myfunction\", &c);\n"

" /* a complex, also providing a function name for errors */\n"

" /* Possible Python call: myfunction(1+2j) */\n"

"}"

msgstr ""

msgid "Keyword Parameters for Extension Functions"

msgstr "Parametry kluczowe dla zadań rozszerzających"

msgid ""

"If you also want your function to accept :term:`keyword arguments <keyword "

"argument>`, use the :c:data:`METH_KEYWORDS` flag in combination with :c:data:"

"`METH_VARARGS`. (:c:data:`!METH_KEYWORDS` can also be used with other flags; "

"see its documentation for the allowed combinations.)"

msgstr ""

msgid ""

"In this case, the C function should accept a third ``PyObject *`` parameter "

"which will be a dictionary of keywords. Use :c:func:"

"`PyArg_ParseTupleAndKeywords` to parse the arguments to such a function."

msgstr ""

msgid ""

"The :c:func:`PyArg_ParseTupleAndKeywords` function is declared as follows::"

msgstr ""

msgid ""

"int PyArg_ParseTupleAndKeywords(PyObject *arg, PyObject *kwdict,\n"

" const char *format, char * const "

"*kwlist, ...);"

msgstr ""

msgid ""

"The *arg* and *format* parameters are identical to those of the :c:func:"

"`PyArg_ParseTuple` function. The *kwdict* parameter is the dictionary of "

"keywords received as the third parameter from the Python runtime. The "

"*kwlist* parameter is a ``NULL``-terminated list of strings which identify "

"the parameters; the names are matched with the type information from "

"*format* from left to right. On success, :c:func:"

"`PyArg_ParseTupleAndKeywords` returns true, otherwise it returns false and "

"raises an appropriate exception."

msgstr ""

msgid ""

"Nested tuples cannot be parsed when using keyword arguments! Keyword "

"parameters passed in which are not present in the *kwlist* will cause :exc:"

"`TypeError` to be raised."

msgstr ""

"Zagnieżdźone krotki nie mogą być wczytane gdy używane są parametry słów "

"kluczowych! Parametry słów kluczowych przekazane do zadania które nie są "

"obecne na liście *kwlist* spowodują że wyjątek :exc:`TypeError` zostanie "

"zgłoszony."

msgid ""

"Here is an example module which uses keywords, based on an example by Geoff "

"Philbrick (philbrick@hks.com)::"

msgstr ""

"Tu jest przykładowy moduł który używa słów kluczowych, oparty na przykładzie "

"Geoffa Philbricka (philbrick@hks.com)::"

msgid ""

"#define PY_SSIZE_T_CLEAN\n"

"#include <Python.h>\n"

"\n"

"static PyObject *\n"

"keywdarg_parrot(PyObject *self, PyObject *args, PyObject *keywds)\n"

"{\n"

" int voltage;\n"

" const char *state = \"a stiff\";\n"

" const char *action = \"voom\";\n"

" const char *type = \"Norwegian Blue\";\n"

"\n"

" static char *kwlist[] = {\"voltage\", \"state\", \"action\", \"type\", "

"NULL};\n"

"\n"

" if (!PyArg_ParseTupleAndKeywords(args, keywds, \"i|sss\", kwlist,\n"

" &voltage, &state, &action, &type))\n"

" return NULL;\n"

"\n"

" printf(\"-- This parrot wouldn't %s if you put %i Volts through it."

"\\n\",\n"

" action, voltage);\n"

" printf(\"-- Lovely plumage, the %s -- It's %s!\\n\", type, state);\n"

"\n"

" Py_RETURN_NONE;\n"

"}\n"

"\n"

"static PyMethodDef keywdarg_methods[] = {\n"

" /* The cast of the function is necessary since PyCFunction values\n"

" * only take two PyObject* parameters, and keywdarg_parrot() takes\n"

" * three.\n"

" */\n"

" {\"parrot\", (PyCFunction)(void(*)(void))keywdarg_parrot, METH_VARARGS | "

"METH_KEYWORDS,\n"

" \"Print a lovely skit to standard output.\"},\n"

" {NULL, NULL, 0, NULL} /* sentinel */\n"

"};"

msgstr ""

msgid "Building Arbitrary Values"

msgstr "Budowanie dowolnych wartości"

msgid ""

"This function is the counterpart to :c:func:`PyArg_ParseTuple`. It is "

"declared as follows::"

msgstr ""

msgid "PyObject *Py_BuildValue(const char *format, ...);"

msgstr ""

msgid ""

"It recognizes a set of format units similar to the ones recognized by :c:"

"func:`PyArg_ParseTuple`, but the arguments (which are input to the function, "

"not output) must not be pointers, just values. It returns a new Python "

"object, suitable for returning from a C function called from Python."

msgstr ""

msgid ""

"One difference with :c:func:`PyArg_ParseTuple`: while the latter requires "

"its first argument to be a tuple (since Python argument lists are always "

"represented as tuples internally), :c:func:`Py_BuildValue` does not always "

"build a tuple. It builds a tuple only if its format string contains two or "

"more format units. If the format string is empty, it returns ``None``; if it "

"contains exactly one format unit, it returns whatever object is described by "

"that format unit. To force it to return a tuple of size 0 or one, "

"parenthesize the format string."

msgstr ""

msgid ""

"Examples (to the left the call, to the right the resulting Python value):"

msgstr ""

msgid ""

"Py_BuildValue(\"\") None\n"

"Py_BuildValue(\"i\", 123) 123\n"

"Py_BuildValue(\"iii\", 123, 456, 789) (123, 456, 789)\n"

"Py_BuildValue(\"s\", \"hello\") 'hello'\n"

"Py_BuildValue(\"y\", \"hello\") b'hello'\n"

"Py_BuildValue(\"ss\", \"hello\", \"world\") ('hello', 'world')\n"

"Py_BuildValue(\"s#\", \"hello\", 4) 'hell'\n"

"Py_BuildValue(\"y#\", \"hello\", 4) b'hell'\n"

"Py_BuildValue(\"()\") ()\n"

"Py_BuildValue(\"(i)\", 123) (123,)\n"

"Py_BuildValue(\"(ii)\", 123, 456) (123, 456)\n"

"Py_BuildValue(\"(i,i)\", 123, 456) (123, 456)\n"

"Py_BuildValue(\"[i,i]\", 123, 456) [123, 456]\n"

"Py_BuildValue(\"{s:i,s:i}\",\n"

" \"abc\", 123, \"def\", 456) {'abc': 123, 'def': 456}\n"

"Py_BuildValue(\"((ii)(ii)) (ii)\",\n"

" 1, 2, 3, 4, 5, 6) (((1, 2), (3, 4)), (5, 6))"

msgstr ""

msgid "Reference Counts"

msgstr "Liczby odniesień"

msgid ""

"In languages like C or C++, the programmer is responsible for dynamic "

"allocation and deallocation of memory on the heap. In C, this is done using "

"the functions :c:func:`malloc` and :c:func:`free`. In C++, the operators "

"``new`` and ``delete`` are used with essentially the same meaning and we'll "

"restrict the following discussion to the C case."

msgstr ""

msgid ""

"Every block of memory allocated with :c:func:`malloc` should eventually be "

"returned to the pool of available memory by exactly one call to :c:func:"

"`free`. It is important to call :c:func:`free` at the right time. If a "

"block's address is forgotten but :c:func:`free` is not called for it, the "

"memory it occupies cannot be reused until the program terminates. This is "

"called a :dfn:`memory leak`. On the other hand, if a program calls :c:func:"

"`free` for a block and then continues to use the block, it creates a "

"conflict with reuse of the block through another :c:func:`malloc` call. "

"This is called :dfn:`using freed memory`. It has the same bad consequences "

"as referencing uninitialized data --- core dumps, wrong results, mysterious "

"crashes."

msgstr ""

msgid ""

"Common causes of memory leaks are unusual paths through the code. For "

"instance, a function may allocate a block of memory, do some calculation, "

"and then free the block again. Now a change in the requirements for the "

"function may add a test to the calculation that detects an error condition "

"and can return prematurely from the function. It's easy to forget to free "

"the allocated memory block when taking this premature exit, especially when "

"it is added later to the code. Such leaks, once introduced, often go "

"undetected for a long time: the error exit is taken only in a small fraction "

"of all calls, and most modern machines have plenty of virtual memory, so the "

"leak only becomes apparent in a long-running process that uses the leaking "

"function frequently. Therefore, it's important to prevent leaks from "

"happening by having a coding convention or strategy that minimizes this kind "

"of errors."

msgstr ""

"Typowymi przyczynami wycieków pamięci są nietypowe ścieżki przejścia przez "

"kod. Dla przykładu, zadanie może zaalokować blok pamięci, wykonać pewne "

"obliczenia, a potem uwolnić ten blok jeszcze raz. Teraz zmiana w wymaganiach "

"dla zadania może dodać test do obliczenia który wykrywa warunek błędu i może "

"wrócić wcześniej z zadania. Łatwo jest zapomnieć aby uwolnić zaalokowany "

"blok pamięci podczas wybierania tej drogi wcześniejszego zakończenia, "

"szczególnie gdy jest dodawane później do kodu. Takie przecieki, gdy raz "

"wprowadzone, często uchodzą niewykryte przez długi czas: błędne wyjście jest "

"wybierane tylko w małym wycinku wszystkich wywołań, i większość nowoczesnych "

"maszyn ma mnóstwo wirtualnej pamięci, tak że wyciek staje się widoczny tylko "

"w długo działającym procesie który używa cieknącego zadania często. Dlatego "

"też, jest to ważne aby zapobiegać wyciekom przed ich nastąpieniem, przez "

"powzięcie konwencji kodowania lub strategii która minimalizuje ten rodzaj "

"błędu."

msgid ""

"Since Python makes heavy use of :c:func:`malloc` and :c:func:`free`, it "

"needs a strategy to avoid memory leaks as well as the use of freed memory. "

"The chosen method is called :dfn:`reference counting`. The principle is "

"simple: every object contains a counter, which is incremented when a "

"reference to the object is stored somewhere, and which is decremented when a "

"reference to it is deleted. When the counter reaches zero, the last "

"reference to the object has been deleted and the object is freed."

msgstr ""

msgid ""

"An alternative strategy is called :dfn:`automatic garbage collection`. "

"(Sometimes, reference counting is also referred to as a garbage collection "

"strategy, hence my use of \"automatic\" to distinguish the two.) The big "

"advantage of automatic garbage collection is that the user doesn't need to "

"call :c:func:`free` explicitly. (Another claimed advantage is an "

"improvement in speed or memory usage --- this is no hard fact however.) The "

"disadvantage is that for C, there is no truly portable automatic garbage "

"collector, while reference counting can be implemented portably (as long as "

"the functions :c:func:`malloc` and :c:func:`free` are available --- which "

"the C Standard guarantees). Maybe some day a sufficiently portable automatic "

"garbage collector will be available for C. Until then, we'll have to live "

"with reference counts."

msgstr ""

msgid ""

"While Python uses the traditional reference counting implementation, it also "

"offers a cycle detector that works to detect reference cycles. This allows "

"applications to not worry about creating direct or indirect circular "

"references; these are the weakness of garbage collection implemented using "

"only reference counting. Reference cycles consist of objects which contain "

"(possibly indirect) references to themselves, so that each object in the "

"cycle has a reference count which is non-zero. Typical reference counting "

"implementations are not able to reclaim the memory belonging to any objects "

"in a reference cycle, or referenced from the objects in the cycle, even "

"though there are no further references to the cycle itself."

msgstr ""

"Podczas gdy język pytonowski używa tradycyjnego wypełnienia zliczania "

"odniesień, on także oferuje wykrywanie cykli, które pracuje aby wykrywać "

"cykliczne odniesienia. To pozwala aplikacjom nie martwić się o tworzenie "

"bezpośrednich lub pośrednich cyklicznych odniesień; to są słabości "

"wypełnienia zbiórki śmieci opartego jedynie na zliczaniu odniesień. Cykle "

"odniesień składają się z przedmiotów które zawierają (możliwie pośrednio) "

"odniesienia do samych siebie, tak że każdy przedmiot w cyklu ma liczbę "

"odniesień która jest nie-zerowa. Typowe wypełnienia zliczające odniesienia "

"nie są w stanie przejąć z powrotem pamięci należącej do któregokolwiek z "

"przedmiotów w cyklu odniesień, ani do której odnosi się któryś z przedmiotów "

"w cyklu, nawet jeśli nie ma więcej odniesień do cyklu samego w sobie."

msgid ""

"The cycle detector is able to detect garbage cycles and can reclaim them. "

"The :mod:`gc` module exposes a way to run the detector (the :func:`~gc."

"collect` function), as well as configuration interfaces and the ability to "

"disable the detector at runtime."

msgstr ""

msgid "Reference Counting in Python"

msgstr "Zliczanie odniesień w języku pytonowskim"

msgid ""

"There are two macros, ``Py_INCREF(x)`` and ``Py_DECREF(x)``, which handle "

"the incrementing and decrementing of the reference count. :c:func:"

"`Py_DECREF` also frees the object when the count reaches zero. For "

"flexibility, it doesn't call :c:func:`free` directly --- rather, it makes a "

"call through a function pointer in the object's :dfn:`type object`. For "

"this purpose (and others), every object also contains a pointer to its type "

"object."

msgstr ""

msgid ""

"The big question now remains: when to use ``Py_INCREF(x)`` and "

"``Py_DECREF(x)``? Let's first introduce some terms. Nobody \"owns\" an "

"object; however, you can :dfn:`own a reference` to an object. An object's "

"reference count is now defined as the number of owned references to it. The "

"owner of a reference is responsible for calling :c:func:`Py_DECREF` when the "

"reference is no longer needed. Ownership of a reference can be "

"transferred. There are three ways to dispose of an owned reference: pass it "

"on, store it, or call :c:func:`Py_DECREF`. Forgetting to dispose of an owned "

"reference creates a memory leak."

msgstr ""

msgid ""

"It is also possible to :dfn:`borrow` [#borrow]_ a reference to an object. "

"The borrower of a reference should not call :c:func:`Py_DECREF`. The "

"borrower must not hold on to the object longer than the owner from which it "

"was borrowed. Using a borrowed reference after the owner has disposed of it "

"risks using freed memory and should be avoided completely [#dont-check-"

"refcount]_."

msgstr ""

msgid ""

"The advantage of borrowing over owning a reference is that you don't need to "

"take care of disposing of the reference on all possible paths through the "

"code --- in other words, with a borrowed reference you don't run the risk of "

"leaking when a premature exit is taken. The disadvantage of borrowing over "

"owning is that there are some subtle situations where in seemingly correct "

"code a borrowed reference can be used after the owner from which it was "

"borrowed has in fact disposed of it."

msgstr ""

"Zaletą pożyczania ponad posiadaniem odniesienia jest to że nie potrzebujesz "

"zaprzątać swojej uwagi pozbyciem się odniesienia na wszystkich możliwych "

"ścieżkach przejścia przez kod --- innymi słowy, z pożyczonym odniesieniem "

"nie musisz ryzykować wycieku gdy nastąpi przedwczesne wyjście z programu. "

"Wadą pożyczania ponad posiadaniem jest to że istnieją pewne szczególne "

"sytuacje gdzie w wydawałoby się poprawnym kodzie pożyczone odniesienie może "

"być użyte po tym jak właściciel od którego zostało ono pożyczone faktycznie "

"pozbył się go."

msgid ""

"A borrowed reference can be changed into an owned reference by calling :c:"

"func:`Py_INCREF`. This does not affect the status of the owner from which "

"the reference was borrowed --- it creates a new owned reference, and gives "

"full owner responsibilities (the new owner must dispose of the reference "

"properly, as well as the previous owner)."

msgstr ""

msgid "Ownership Rules"

msgstr "Zasady właścicielskie"

msgid ""

"Whenever an object reference is passed into or out of a function, it is part "

"of the function's interface specification whether ownership is transferred "

"with the reference or not."

msgstr ""

"Zawsze gdy odniesienie do przedmiotu jest przekazywane do lub z zadania, "

"jest częścią specyfiki sprzęgu zadania to czy własność jest przekazywana z "

"odniesieniem czy też nie."

msgid ""

"Most functions that return a reference to an object pass on ownership with "

"the reference. In particular, all functions whose function it is to create "

"a new object, such as :c:func:`PyLong_FromLong` and :c:func:`Py_BuildValue`, "

"pass ownership to the receiver. Even if the object is not actually new, you "

"still receive ownership of a new reference to that object. For instance, :c:"

"func:`PyLong_FromLong` maintains a cache of popular values and can return a "

"reference to a cached item."

msgstr ""

msgid ""

"Many functions that extract objects from other objects also transfer "

"ownership with the reference, for instance :c:func:"

"`PyObject_GetAttrString`. The picture is less clear, here, however, since a "

"few common routines are exceptions: :c:func:`PyTuple_GetItem`, :c:func:"

"`PyList_GetItem`, :c:func:`PyDict_GetItem`, and :c:func:"

"`PyDict_GetItemString` all return references that you borrow from the tuple, "

"list or dictionary."

msgstr ""

msgid ""

"The function :c:func:`PyImport_AddModule` also returns a borrowed reference, "

"even though it may actually create the object it returns: this is possible "

"because an owned reference to the object is stored in ``sys.modules``."

msgstr ""

msgid ""

"When you pass an object reference into another function, in general, the "

"function borrows the reference from you --- if it needs to store it, it will "

"use :c:func:`Py_INCREF` to become an independent owner. There are exactly "

"two important exceptions to this rule: :c:func:`PyTuple_SetItem` and :c:func:"

"`PyList_SetItem`. These functions take over ownership of the item passed to "

"them --- even if they fail! (Note that :c:func:`PyDict_SetItem` and friends "

"don't take over ownership --- they are \"normal.\")"

msgstr ""

msgid ""

"When a C function is called from Python, it borrows references to its "

"arguments from the caller. The caller owns a reference to the object, so "

"the borrowed reference's lifetime is guaranteed until the function returns. "

"Only when such a borrowed reference must be stored or passed on, it must be "

"turned into an owned reference by calling :c:func:`Py_INCREF`."

msgstr ""

msgid ""

"The object reference returned from a C function that is called from Python "

"must be an owned reference --- ownership is transferred from the function to "

"its caller."

msgstr ""

"Odniesienie do przedmiotu zwrócone z zadania C które jest wywołane z poziomu "

"języka pytonowskiego musi być posiadanym odniesieniem --- prawo własności "

"jest przekazywane z zadania do wywołującego to ostatnie."

msgid "Thin Ice"

msgstr "Cienki lód"

msgid ""

"There are a few situations where seemingly harmless use of a borrowed "

"reference can lead to problems. These all have to do with implicit "

"invocations of the interpreter, which can cause the owner of a reference to "