@@ -692,22 +692,22 @@ applied, and 136 bugs fixed; both figures are likely to be underestimates. Some
692692of the more notable changes are:
693693
694694* 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
697697 then fulfills smaller memory requests from these pools. It can be enabled by
698698 providing the :option: `!--with-pymalloc ` option to the :program: `configure `
699699 script; see :file: `Objects/obmalloc.c ` for the implementation details.
700700
701701 Authors of C extension modules should test their code with the object allocator
702702 enabled, because some incorrect code may break, causing core dumps at runtime.
703703 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
706706 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
708708 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
711711 fell afoul of this and had to be fixed; doubtless there are more third-party
712712 modules that will have the same problem.
713713
@@ -717,7 +717,7 @@ of the more notable changes are:
717717 complain about its lack of speed, and because it's often been used as a naïve
718718 benchmark. The :meth: `readline ` method of file objects has therefore been
719719 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
721721 is around 66%, and potentially much faster on some particular operating systems.
722722 Tim Peters did much of the benchmarking and coding for this change, motivated by
723723 a discussion in comp.lang.python.
@@ -770,7 +770,7 @@ of the more notable changes are:
770770 reorganization done by Jeremy Hylton.
771771
772772* 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
774774 that have been installed. This is also encouraged for third-party extensions
775775 that need to import some other module from C code.
776776
0 commit comments