iSharkFly-Open
/
python-peps
mirror of https://github.com/python/peps.git
1
0
Fork 0
Code Issues Packages Projects Releases Wiki Activity

PEP 454: uh ho, fix many typos in the Rationale

This commit is contained in:
Victor Stinner 2013-09-04 02:02:50 +02:00
parent bb7b188f66
commit a80266cdc2
1 changed files with 11 additions and 10 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

21
pep-0454.txt
View File

@ -22,20 +22,21 @@ Rationale
Common debug tools tracing memory allocations read the C filename and
number. Using such tool to analyze Python memory allocations does not
help because most memory allocations are done in the same C function,
``PyMem_Malloc()`` for example.
help because most memory block are allocated in the same C function,
in ``PyMem_Malloc()`` for example.
There are debug tools dedicated to the Python languages like ``Heapy``
There are debug tools dedicated to the Python language like ``Heapy``
and ``PySizer``. These projects analyze objects type and/or content.
These tools are useful when the most memory leak are instances of the
same type and this type in allocated only in a few functions. The
These tools are useful when most memory leaks are instances of the
same type and this type is only instancied in a few functions. The
problem is when the object type is very common like ``str`` or
``tuple``, and it is hard to identify where these objects are allocated.
``tuple``, and it is hard to identify where these objects are
instancied.
Finding reference cycles is also a difficult task. There are different
tools to draw a diagram of all references. These tools cannot be used
huge on large applications with thousands of objects because the diagram
is too huge to be analyzed manually.
Finding reference cycles is also a difficult problem. There are
different tools to draw a diagram of all references. These tools cannot
be used on large applications with thousands of objects because the
diagram is too huge to be analyzed manually.
Proposal