Change double hyphens (en dashes) to em (longer) dashes
diff --git a/Doc/howto/clinic.rst b/Doc/howto/clinic.rst
index caa4975..d4fd45c 100644
--- 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.
@@ -424,7 +424,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
@@ -637,7 +637,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
@@ -888,7 +888,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
@@ -1002,7 +1002,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
@@ -1184,7 +1184,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``.
@@ -1226,7 +1226,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
@@ -1402,7 +1402,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
index 27e7e6f..7cacb0a 100644
--- 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.