[Python-checkins] cpython (merge 3.6 -> default): Merge doc fixups from 3.6
martin.panter
python-checkins at python.org
Sun Nov 20 23:23:50 EST 2016
https://hg.python.org/cpython/rev/45eab45be175
changeset: 105260:45eab45be175
parent: 105255:30f154d9abf0
parent: 105259:b72391f54083
user: Martin Panter <vadmium+py at gmail.com>
date: Mon Nov 21 04:22:43 2016 +0000
summary:
Merge doc fixups from 3.6
files:
Doc/howto/clinic.rst | 30 ++++++++++++------------
Doc/howto/cporting.rst | 2 +-
Doc/library/functions.rst | 2 +-
Doc/library/hmac.rst | 2 +-
Doc/library/pdb.rst | 2 +-
Doc/library/shutil.rst | 2 +-
Doc/reference/datamodel.rst | 2 +-
7 files changed, 21 insertions(+), 21 deletions(-)
diff --git a/Doc/howto/clinic.rst b/Doc/howto/clinic.rst
--- a/Doc/howto/clinic.rst
+++ b/Doc/howto/clinic.rst
@@ -30,7 +30,7 @@
is to take over responsibility for all argument parsing code
inside CPython. This means that, when you convert a function
to work with Argument Clinic, that function should no longer
-do any of its own argument parsing--the code generated by
+do any of its own argument parsing—the code generated by
Argument Clinic should be a "black box" to you, where CPython
calls in at the top, and your code gets called at the bottom,
with ``PyObject *args`` (and maybe ``PyObject *kwargs``)
@@ -43,12 +43,12 @@
When you use Argument Clinic, you don't have to repeat yourself.
Obviously, no one would want to use Argument Clinic unless
-it's solving their problem--and without creating new problems of
+it's solving their problem—and without creating new problems of
its own.
So it's paramount that Argument Clinic generate correct code.
It'd be nice if the code was faster, too, but at the very least
it should not introduce a major speed regression. (Eventually Argument
-Clinic *should* make a major speedup possible--we could
+Clinic *should* make a major speedup possible—we could
rewrite its code generator to produce tailor-made argument
parsing code, rather than calling the general-purpose CPython
argument parsing library. That would make for the fastest
@@ -113,7 +113,7 @@
You should never modify the output portion of an Argument Clinic block. Instead,
change the input until it produces the output you want. (That's the purpose of the
-checksum--to detect if someone changed the output, as these edits would be lost
+checksum—to detect if someone changed the output, as these edits would be lost
the next time Argument Clinic writes out fresh output.)
For the sake of clarity, here's the terminology we'll use with Argument Clinic:
@@ -166,7 +166,7 @@
or if it has multiple calls to :c:func:`PyArg_ParseTuple`,
you should choose a different function. Argument Clinic *does*
support all of these scenarios. But these are advanced
- topics--let's do something simpler for your first function.
+ topics—let's do something simpler for your first function.
Also, if the function has multiple calls to :c:func:`PyArg_ParseTuple`
or :c:func:`PyArg_ParseTupleAndKeywords` where it supports different
@@ -188,7 +188,7 @@
If the old docstring had a first line that looked like a function
signature, throw that line away. (The docstring doesn't need it
- anymore--when you use ``help()`` on your builtin in the future,
+ anymore—when you use ``help()`` on your builtin in the future,
the first line will be built automatically based on the function's
signature.)
@@ -209,7 +209,7 @@
6. Above the docstring, enter the name of the function, followed
by a blank line. This should be the Python name of the function,
and should be the full dotted path
- to the function--it should start with the name of the module,
+ to the function—it should start with the name of the module,
include any sub-modules, and if the function is a method on
a class it should include the class name too.
@@ -275,7 +275,7 @@
What's a "converter"? It establishes both the type
of the variable used in C, and the method to convert the Python
value into a C value at runtime.
- For now you're going to use what's called a "legacy converter"--a
+ For now you're going to use what's called a "legacy converter"—a
convenience syntax intended to make porting old code into Argument
Clinic easier.
@@ -425,7 +425,7 @@
(Argument Clinic always generates its format strings
with a ``:`` followed by the name of the function. If the
existing code's format string ends with ``;``, to provide
- usage help, this change is harmless--don't worry about it.)
+ usage help, this change is harmless—don't worry about it.)
Third, for parameters whose format units require two arguments
(like a length variable, or an encoding string, or a pointer
@@ -638,7 +638,7 @@
Another example is ``curses.window.addch()``, which has a group of two
arguments that must always be specified together. (The arguments are
called ``x`` and ``y``; if you call the function passing in ``x``,
-you must also pass in ``y``--and if you don't pass in ``x`` you may not
+you must also pass in ``y``—and if you don't pass in ``x`` you may not
pass in ``y`` either.)
In any case, the goal of Argument Clinic is to support argument parsing
@@ -889,7 +889,7 @@
Remember those format units you skipped for your first
time because they were advanced? Here's how to handle those too.
-The trick is, all those format units take arguments--either
+The trick is, all those format units take arguments—either
conversion functions, or types, or strings specifying an encoding.
(But "legacy converters" don't support arguments. That's why we
skipped them for your first function.) The argument you specified
@@ -1003,7 +1003,7 @@
By default the impl function Argument Clinic generates for you returns ``PyObject *``.
But your C function often computes some C type, then converts it into the ``PyObject *``
at the last moment. Argument Clinic handles converting your inputs from Python types
-into native C types--why not have it convert your return value from a native C type
+into native C types—why not have it convert your return value from a native C type
into a Python type too?
That's what a "return converter" does. It changes your impl function to return
@@ -1185,7 +1185,7 @@
As we hinted at in the previous section... you can write your own converters!
A converter is simply a Python class that inherits from ``CConverter``.
The main purpose of a custom converter is if you have a parameter using
-the ``O&`` format unit--parsing this parameter means calling
+the ``O&`` format unit—parsing this parameter means calling
a :c:func:`PyArg_ParseTuple` "converter function".
Your converter class should be named ``*something*_converter``.
@@ -1227,7 +1227,7 @@
The default value used to initialize the C variable when
there is no default, but not specifying a default may
result in an "uninitialized variable" warning. This can
- easily happen when using option groups--although
+ easily happen when using option groups—although
properly-written code will never actually use this value,
the variable does get passed in to the impl, and the
C compiler will complain about the "use" of the
@@ -1403,7 +1403,7 @@
all of processing, even from Clinic blocks *after* the
``suppress``
- The text is suppressed--thrown away.
+ The text is suppressed—thrown away.
Clinic defines five new directives that let you reconfigure its output.
diff --git a/Doc/howto/cporting.rst b/Doc/howto/cporting.rst
--- a/Doc/howto/cporting.rst
+++ b/Doc/howto/cporting.rst
@@ -95,7 +95,7 @@
--------------------
Python 3 has only one integer type, :func:`int`. But it actually
-corresponds to Python 2's :func:`long` type--the :func:`int` type
+corresponds to Python 2's :func:`long` type—the :func:`int` type
used in Python 2 was removed. In the C-API, ``PyInt_*`` functions
are replaced by their ``PyLong_*`` equivalents.
diff --git a/Doc/library/functions.rst b/Doc/library/functions.rst
--- a/Doc/library/functions.rst
+++ b/Doc/library/functions.rst
@@ -959,7 +959,7 @@
the list of supported encodings.
*errors* is an optional string that specifies how encoding and decoding
- errors are to be handled--this cannot be used in binary mode.
+ errors are to be handled—this cannot be used in binary mode.
A variety of standard error handlers are available
(listed under :ref:`error-handlers`), though any
error handling name that has been registered with
diff --git a/Doc/library/hmac.rst b/Doc/library/hmac.rst
--- a/Doc/library/hmac.rst
+++ b/Doc/library/hmac.rst
@@ -111,7 +111,7 @@
If *a* and *b* are of different lengths, or if an error occurs,
a timing attack could theoretically reveal information about the
- types and lengths of *a* and *b*--but not their values.
+ types and lengths of *a* and *b*—but not their values.
.. versionadded:: 3.3
diff --git a/Doc/library/pdb.rst b/Doc/library/pdb.rst
--- a/Doc/library/pdb.rst
+++ b/Doc/library/pdb.rst
@@ -334,7 +334,7 @@
return, jump, quit and their abbreviations) terminates the command list (as if
that command was immediately followed by end). This is because any time you
resume execution (even with a simple next or step), you may encounter another
- breakpoint--which could have its own command list, leading to ambiguities about
+ breakpoint—which could have its own command list, leading to ambiguities about
which list to execute.
If you use the 'silent' command in the command list, the usual message about
diff --git a/Doc/library/shutil.rst b/Doc/library/shutil.rst
--- a/Doc/library/shutil.rst
+++ b/Doc/library/shutil.rst
@@ -107,7 +107,7 @@
If *follow_symlinks* is false, and *src* and *dst* both
refer to symbolic links, :func:`copystat` will operate on
the symbolic links themselves rather than the files the
- symbolic links refer to--reading the information from the
+ symbolic links refer to—reading the information from the
*src* symbolic link, and writing the information to the
*dst* symbolic link.
diff --git a/Doc/reference/datamodel.rst b/Doc/reference/datamodel.rst
--- a/Doc/reference/datamodel.rst
+++ b/Doc/reference/datamodel.rst
@@ -2550,7 +2550,7 @@
.. [#] "Does not support" here means that the class has no such method, or
the method returns ``NotImplemented``. Do not set the method to
``None`` if you want to force fallback to the right operand's reflected
- method--that will instead have the opposite effect of explicitly
+ method—that will instead have the opposite effect of explicitly
*blocking* such fallback.
.. [#] For operands of the same type, it is assumed that if the non-reflected method
--
Repository URL: https://hg.python.org/cpython
More information about the Python-checkins
mailing list