# SOME DESCRIPTIVE TITLE. # Copyright (C) 1990-2016, Python Software Foundation # This file is distributed under the same license as the Python package. # FIRST AUTHOR , YEAR. # #, fuzzy msgid "" msgstr "" "Project-Id-Version: Python 2.7\n" "Report-Msgid-Bugs-To: \n" "POT-Creation-Date: 2016-10-30 10:44+0100\n" "PO-Revision-Date: YEAR-MO-DA HO:MI+ZONE\n" "Last-Translator: FULL NAME \n" "Language-Team: LANGUAGE \n" "MIME-Version: 1.0\n" "Content-Type: text/plain; charset=UTF-8\n" "Content-Transfer-Encoding: 8bit\n" #: ../Doc/c-api/memory.rst:8 msgid "Memory Management" msgstr "" #: ../Doc/c-api/memory.rst:17 msgid "Overview" msgstr "" #: ../Doc/c-api/memory.rst:19 msgid "" "Memory management in Python involves a private heap containing all Python " "objects and data structures. The management of this private heap is ensured " "internally by the *Python memory manager*. The Python memory manager has " "different components which deal with various dynamic storage management " "aspects, like sharing, segmentation, preallocation or caching." msgstr "" #: ../Doc/c-api/memory.rst:25 msgid "" "At the lowest level, a raw memory allocator ensures that there is enough " "room in the private heap for storing all Python-related data by interacting " "with the memory manager of the operating system. On top of the raw memory " "allocator, several object-specific allocators operate on the same heap and " "implement distinct memory management policies adapted to the peculiarities " "of every object type. For example, integer objects are managed differently " "within the heap than strings, tuples or dictionaries because integers imply " "different storage requirements and speed/space tradeoffs. The Python memory " "manager thus delegates some of the work to the object-specific allocators, " "but ensures that the latter operate within the bounds of the private heap." msgstr "" #: ../Doc/c-api/memory.rst:36 msgid "" "It is important to understand that the management of the Python heap is " "performed by the interpreter itself and that the user has no control over " "it, even if she regularly manipulates object pointers to memory blocks " "inside that heap. The allocation of heap space for Python objects and other " "internal buffers is performed on demand by the Python memory manager through " "the Python/C API functions listed in this document." msgstr "" #: ../Doc/c-api/memory.rst:49 msgid "" "To avoid memory corruption, extension writers should never try to operate on " "Python objects with the functions exported by the C library: :c:func:" "`malloc`, :c:func:`calloc`, :c:func:`realloc` and :c:func:`free`. This will " "result in mixed calls between the C allocator and the Python memory manager " "with fatal consequences, because they implement different algorithms and " "operate on different heaps. However, one may safely allocate and release " "memory blocks with the C library allocator for individual purposes, as shown " "in the following example::" msgstr "" #: ../Doc/c-api/memory.rst:68 msgid "" "In this example, the memory request for the I/O buffer is handled by the C " "library allocator. The Python memory manager is involved only in the " "allocation of the string object returned as a result." msgstr "" #: ../Doc/c-api/memory.rst:72 msgid "" "In most situations, however, it is recommended to allocate memory from the " "Python heap specifically because the latter is under control of the Python " "memory manager. For example, this is required when the interpreter is " "extended with new object types written in C. Another reason for using the " "Python heap is the desire to *inform* the Python memory manager about the " "memory needs of the extension module. Even when the requested memory is used " "exclusively for internal, highly-specific purposes, delegating all memory " "requests to the Python memory manager causes the interpreter to have a more " "accurate image of its memory footprint as a whole. Consequently, under " "certain circumstances, the Python memory manager may or may not trigger " "appropriate actions, like garbage collection, memory compaction or other " "preventive procedures. Note that by using the C library allocator as shown " "in the previous example, the allocated memory for the I/O buffer escapes " "completely the Python memory manager." msgstr "" #: ../Doc/c-api/memory.rst:90 msgid "Memory Interface" msgstr "" #: ../Doc/c-api/memory.rst:92 msgid "" "The following function sets, modeled after the ANSI C standard, but " "specifying behavior when requesting zero bytes, are available for allocating " "and releasing memory from the Python heap:" msgstr "" #: ../Doc/c-api/memory.rst:99 msgid "" "Allocates *n* bytes and returns a pointer of type :c:type:`void\\*` to the " "allocated memory, or *NULL* if the request fails. Requesting zero bytes " "returns a distinct non-*NULL* pointer if possible, as if ``PyMem_Malloc(1)`` " "had been called instead. The memory will not have been initialized in any " "way." msgstr "" #: ../Doc/c-api/memory.rst:107 msgid "" "Resizes the memory block pointed to by *p* to *n* bytes. The contents will " "be unchanged to the minimum of the old and the new sizes. If *p* is *NULL*, " "the call is equivalent to ``PyMem_Malloc(n)``; else if *n* is equal to zero, " "the memory block is resized but is not freed, and the returned pointer is " "non-*NULL*. Unless *p* is *NULL*, it must have been returned by a previous " "call to :c:func:`PyMem_Malloc` or :c:func:`PyMem_Realloc`. If the request " "fails, :c:func:`PyMem_Realloc` returns *NULL* and *p* remains a valid " "pointer to the previous memory area." msgstr "" #: ../Doc/c-api/memory.rst:119 msgid "" "Frees the memory block pointed to by *p*, which must have been returned by a " "previous call to :c:func:`PyMem_Malloc` or :c:func:`PyMem_Realloc`. " "Otherwise, or if ``PyMem_Free(p)`` has been called before, undefined " "behavior occurs. If *p* is *NULL*, no operation is performed." msgstr "" #: ../Doc/c-api/memory.rst:124 msgid "" "The following type-oriented macros are provided for convenience. Note that " "*TYPE* refers to any C type." msgstr "" #: ../Doc/c-api/memory.rst:130 msgid "" "Same as :c:func:`PyMem_Malloc`, but allocates ``(n * sizeof(TYPE))`` bytes " "of memory. Returns a pointer cast to :c:type:`TYPE\\*`. The memory will " "not have been initialized in any way." msgstr "" #: ../Doc/c-api/memory.rst:137 msgid "" "Same as :c:func:`PyMem_Realloc`, but the memory block is resized to ``(n * " "sizeof(TYPE))`` bytes. Returns a pointer cast to :c:type:`TYPE\\*`. On " "return, *p* will be a pointer to the new memory area, or *NULL* in the event " "of failure. This is a C preprocessor macro; p is always reassigned. Save " "the original value of p to avoid losing memory when handling errors." msgstr "" #: ../Doc/c-api/memory.rst:146 msgid "Same as :c:func:`PyMem_Free`." msgstr "" #: ../Doc/c-api/memory.rst:148 msgid "" "In addition, the following macro sets are provided for calling the Python " "memory allocator directly, without involving the C API functions listed " "above. However, note that their use does not preserve binary compatibility " "across Python versions and is therefore deprecated in extension modules." msgstr "" #: ../Doc/c-api/memory.rst:153 msgid ":c:func:`PyMem_MALLOC`, :c:func:`PyMem_REALLOC`, :c:func:`PyMem_FREE`." msgstr "" #: ../Doc/c-api/memory.rst:155 msgid ":c:func:`PyMem_NEW`, :c:func:`PyMem_RESIZE`, :c:func:`PyMem_DEL`." msgstr "" #: ../Doc/c-api/memory.rst:161 msgid "Examples" msgstr "Exemples" #: ../Doc/c-api/memory.rst:163 msgid "" "Here is the example from section :ref:`memoryoverview`, rewritten so that " "the I/O buffer is allocated from the Python heap by using the first function " "set::" msgstr "" #: ../Doc/c-api/memory.rst:176 msgid "The same code using the type-oriented function set::" msgstr "" #: ../Doc/c-api/memory.rst:188 msgid "" "Note that in the two examples above, the buffer is always manipulated via " "functions belonging to the same set. Indeed, it is required to use the same " "memory API family for a given memory block, so that the risk of mixing " "different allocators is reduced to a minimum. The following code sequence " "contains two errors, one of which is labeled as *fatal* because it mixes two " "different allocators operating on different heaps. ::" msgstr "" #: ../Doc/c-api/memory.rst:203 msgid "" "In addition to the functions aimed at handling raw memory blocks from the " "Python heap, objects in Python are allocated and released with :c:func:" "`PyObject_New`, :c:func:`PyObject_NewVar` and :c:func:`PyObject_Del`." msgstr "" #: ../Doc/c-api/memory.rst:207 msgid "" "These will be explained in the next chapter on defining and implementing new " "object types in C." msgstr ""