diff --git a/Doc/howto/pyporting.rst b/Doc/howto/pyporting.rst index e1a460991a7..483dcae6869 100644 --- a/Doc/howto/pyporting.rst +++ b/Doc/howto/pyporting.rst @@ -535,7 +535,7 @@ Update ``map`` for imbalanced input sequences ''''''''''''''''''''''''''''''''''''''''''''' With Python 2, when ``map`` was given more than one input sequence it would pad -the shorter sequences with `None` values, returning a sequence as long as the +the shorter sequences with ``None`` values, returning a sequence as long as the longest input sequence. With Python 3, if the input sequences to ``map`` are of unequal length, ``map`` diff --git a/Doc/library/ctypes.rst b/Doc/library/ctypes.rst index a071edc0033..4109d56b0bd 100644 --- a/Doc/library/ctypes.rst +++ b/Doc/library/ctypes.rst @@ -1090,7 +1090,7 @@ As we can easily check, our array is sorted now:: outside of Python's control (e.g. by the foreign code that calls the callback), ctypes creates a new dummy Python thread on every invocation. This behavior is correct for most purposes, but it means that values stored with - `threading.local` will *not* survive across different callbacks, even when + :class:`threading.local` will *not* survive across different callbacks, even when those calls are made from the same C thread. .. _ctypes-accessing-values-exported-from-dlls: