Avoid using the default reST role in PEP-404.
This commit is contained in:
parent
e309749ebb
commit
8b65016bca
16
pep-0404.txt
16
pep-0404.txt
|
@ -93,7 +93,7 @@ sequences. While Python 2 also has a unicode string type, the
|
|||
fundamental ambiguity of the core string type, coupled with Python 2's
|
||||
default behavior of supporting automatic coercion from 8-bit strings
|
||||
to unicode objects when the two are combined, often leads to
|
||||
`UnicodeError`\ s. Python 3's standard string type is Unicode based, and
|
||||
``UnicodeError``\ s. Python 3's standard string type is Unicode based, and
|
||||
Python 3 adds a dedicated bytes type, but critically, no automatic coercion
|
||||
between bytes and unicode strings is provided. The closest the language gets
|
||||
to implicit coercion are a few text-based APIs that assume a default
|
||||
|
@ -106,16 +106,16 @@ natively supported.
|
|||
This string/bytes clarity is often a source of difficulty in
|
||||
transitioning existing code to Python 3, because many third party
|
||||
libraries and applications are themselves ambiguous in this
|
||||
distinction. Once migrated though, most `UnicodeError`\ s can be
|
||||
distinction. Once migrated though, most ``UnicodeError``\ s can be
|
||||
eliminated.
|
||||
|
||||
|
||||
Numbers
|
||||
-------
|
||||
|
||||
Python 2 has two basic integer types, a native machine-sized `int`
|
||||
type, and an arbitrary length `long` type. These have been merged in
|
||||
Python 3 into a single `int` type analogous to Python 2's `long`
|
||||
Python 2 has two basic integer types, a native machine-sized ``int``
|
||||
type, and an arbitrary length ``long`` type. These have been merged in
|
||||
Python 3 into a single ``int`` type analogous to Python 2's ``long``
|
||||
type.
|
||||
|
||||
In addition, integer division now produces floating point numbers for
|
||||
|
@ -146,9 +146,9 @@ Multiple spellings
|
|||
------------------
|
||||
|
||||
There are many cases in Python 2 where multiple spellings of some
|
||||
constructs exist, such as `repr()` and *backticks*, or the two
|
||||
inequality operators `!=` and `<>`. In all cases, Python 3 has chosen
|
||||
exactly one spelling and removed the other (e.g. `repr()` and `!=`
|
||||
constructs exist, such as ``repr()`` and *backticks*, or the two
|
||||
inequality operators ``!=`` and ``<>``. In all cases, Python 3 has chosen
|
||||
exactly one spelling and removed the other (e.g. ``repr()`` and ``!=``
|
||||
were kept).
|
||||
|
||||
|
||||
|
|
Loading…
Reference in New Issue