@@ -692,22 +692,22 @@ applied, and 136 bugs fixed; both figures are likely to be underestimates. Some
692
692
of the more notable changes are:
693
693
694
694
* A specialized object allocator is now optionally available, that should be
695
- faster than the system :func: `malloc ` and have less memory overhead. The
696
- allocator uses C's :func: `malloc ` function to get large pools of memory, and
695
+ faster than the system :c: func: `malloc ` and have less memory overhead. The
696
+ allocator uses C's :c: func: `! malloc ` function to get large pools of memory, and
697
697
then fulfills smaller memory requests from these pools. It can be enabled by
698
698
providing the :option: `!--with-pymalloc ` option to the :program: `configure `
699
699
script; see :file: `Objects/obmalloc.c ` for the implementation details.
700
700
701
701
Authors of C extension modules should test their code with the object allocator
702
702
enabled, because some incorrect code may break, causing core dumps at runtime.
703
703
There are a bunch of memory allocation functions in Python's C API that have
704
- previously been just aliases for the C library's :func: `malloc ` and
705
- :func: `free `, meaning that if you accidentally called mismatched functions, the
704
+ previously been just aliases for the C library's :c: func: `malloc ` and
705
+ :c: func: `free `, meaning that if you accidentally called mismatched functions, the
706
706
error wouldn't be noticeable. When the object allocator is enabled, these
707
- functions aren't aliases of :func: `malloc ` and :func: `free ` any more, and
707
+ functions aren't aliases of :c: func: `! malloc ` and :c: func: `! free ` any more, and
708
708
calling the wrong function to free memory will get you a core dump. For
709
- example, if memory was allocated using :func : `PyMem_New `, it has to be freed
710
- using :func: `PyMem_Del `, not :func: `free `. A few modules included with Python
709
+ example, if memory was allocated using :c:macro : `PyMem_New `, it has to be freed
710
+ using :c: func: `PyMem_Del `, not :c: func: `! free `. A few modules included with Python
711
711
fell afoul of this and had to be fixed; doubtless there are more third-party
712
712
modules that will have the same problem.
713
713
@@ -717,7 +717,7 @@ of the more notable changes are:
717
717
complain about its lack of speed, and because it's often been used as a naïve
718
718
benchmark. The :meth: `readline ` method of file objects has therefore been
719
719
rewritten to be much faster. The exact amount of the speedup will vary from
720
- platform to platform depending on how slow the C library's :func: `getc ` was, but
720
+ platform to platform depending on how slow the C library's :c: func: `! getc ` was, but
721
721
is around 66%, and potentially much faster on some particular operating systems.
722
722
Tim Peters did much of the benchmarking and coding for this change, motivated by
723
723
a discussion in comp.lang.python.
@@ -770,7 +770,7 @@ of the more notable changes are:
770
770
reorganization done by Jeremy Hylton.
771
771
772
772
* C extensions which import other modules have been changed to use
773
- :func: `PyImport_ImportModule `, which means that they will use any import hooks
773
+ :c: func: `PyImport_ImportModule `, which means that they will use any import hooks
774
774
that have been installed. This is also encouraged for third-party extensions
775
775
that need to import some other module from C code.
776
776
0 commit comments