#2762: remove 2.x remnants and patch up some new documentation.
This commit is contained in:
parent
7694100e4b
commit
e06de8b3cc
|
@ -209,15 +209,15 @@ are always available. They are listed here in alphabetical order.
|
|||
case, expression statements that evaluate to something else than
|
||||
``None`` will be printed).
|
||||
|
||||
The optional arguments *flags* and *dont_inherit* (which are new in Python 2.2)
|
||||
control which future statements (see :pep:`236`) affect the compilation of
|
||||
*source*. If neither is present (or both are zero) the code is compiled with
|
||||
those future statements that are in effect in the code that is calling compile.
|
||||
If the *flags* argument is given and *dont_inherit* is not (or is zero) then the
|
||||
The optional arguments *flags* and *dont_inherit* control which future
|
||||
statements (see :pep:`236`) affect the compilation of *source*. If neither
|
||||
is present (or both are zero) the code is compiled with those future
|
||||
statements that are in effect in the code that is calling compile. If the
|
||||
*flags* argument is given and *dont_inherit* is not (or is zero) then the
|
||||
future statements specified by the *flags* argument are used in addition to
|
||||
those that would be used anyway. If *dont_inherit* is a non-zero integer then
|
||||
the *flags* argument is it -- the future statements in effect around the call to
|
||||
compile are ignored.
|
||||
the *flags* argument is it -- the future statements in effect around the call
|
||||
to compile are ignored.
|
||||
|
||||
Future statements are specified by bits which can be bitwise ORed together to
|
||||
specify multiple statements. The bitfield required to specify a given feature
|
||||
|
@ -813,19 +813,14 @@ are always available. They are listed here in alphabetical order.
|
|||
modulo *z* (computed more efficiently than ``pow(x, y) % z``). The two-argument
|
||||
form ``pow(x, y)`` is equivalent to using the power operator: ``x**y``.
|
||||
|
||||
The arguments must have numeric types. With mixed operand types, the coercion
|
||||
rules for binary arithmetic operators apply. For :class:`int` operands, the
|
||||
result has the same type as the operands (after coercion) unless the second
|
||||
argument is negative; in that case, all arguments are converted to float and a
|
||||
float result is delivered. For example, ``10**2`` returns ``100``, but
|
||||
``10**-2`` returns ``0.01``. (This last feature was added in Python 2.2. In
|
||||
Python 2.1 and before, if both arguments were of integer types and the second
|
||||
argument was negative, an exception was raised.) If the second argument is
|
||||
negative, the third argument must be omitted. If *z* is present, *x* and *y*
|
||||
must be of integer types, and *y* must be non-negative. (This restriction was
|
||||
added in Python 2.2. In Python 2.1 and before, floating 3-argument ``pow()``
|
||||
returned platform-dependent results depending on floating-point rounding
|
||||
accidents.)
|
||||
The arguments must have numeric types. With mixed operand types, the
|
||||
coercion rules for binary arithmetic operators apply. For :class:`int`
|
||||
operands, the result has the same type as the operands (after coercion)
|
||||
unless the second argument is negative; in that case, all arguments are
|
||||
converted to float and a float result is delivered. For example, ``10**2``
|
||||
returns ``100``, but ``10**-2`` returns ``0.01``. If the second argument is
|
||||
negative, the third argument must be omitted. If *z* is present, *x* and *y*
|
||||
must be of integer types, and *y* must be non-negative.
|
||||
|
||||
|
||||
.. function:: print([object, ...][, sep=' '][, end='\n'][, file=sys.stdout])
|
||||
|
|
|
@ -334,12 +334,6 @@ Additional information on exceptions can be found in section :ref:`exceptions`,
|
|||
and information on using the :keyword:`raise` statement to generate exceptions
|
||||
may be found in section :ref:`raise`.
|
||||
|
||||
.. seealso::
|
||||
|
||||
:pep:`3110` - Catching exceptions in Python 3000
|
||||
Describes the differences in :keyword:`try` statements between Python 2.x
|
||||
and 3.0.
|
||||
|
||||
|
||||
.. _with:
|
||||
.. _as:
|
||||
|
@ -390,11 +384,6 @@ The execution of the :keyword:`with` statement proceeds as follows:
|
|||
value from :meth:`__exit__` is ignored, and execution proceeds at the normal
|
||||
location for the kind of exit that was taken.
|
||||
|
||||
|
||||
In Python 2.5, the :keyword:`with` statement is only allowed when the
|
||||
``with_statement`` feature has been enabled. It is always enabled in
|
||||
Python 2.6.
|
||||
|
||||
.. seealso::
|
||||
|
||||
:pep:`0343` - The "with" statement
|
||||
|
|
|
@ -510,10 +510,6 @@ Callable types
|
|||
An instance method object combines a class, a class instance and any
|
||||
callable object (normally a user-defined function).
|
||||
|
||||
.. versionchanged:: 2.6
|
||||
For 3.0 forward-compatibility, :attr:`im_func` is also available as
|
||||
:attr:`__func__`, and :attr:`im_self` as :attr:`__self__`.
|
||||
|
||||
.. index::
|
||||
single: __func__ (method attribute)
|
||||
single: __self__ (method attribute)
|
||||
|
|
|
@ -270,16 +270,20 @@ Identifiers and keywords
|
|||
.. index:: identifier, name
|
||||
|
||||
Identifiers (also referred to as *names*) are described by the following lexical
|
||||
definitions:
|
||||
definitions.
|
||||
|
||||
The syntax of identifiers in Python is based on the Unicode standard annex
|
||||
UAX-31, with elaboration and changes as defined below.
|
||||
UAX-31, with elaboration and changes as defined below; see also :pep:`3131` for
|
||||
further details.
|
||||
|
||||
Within the ASCII range (U+0001..U+007F), the valid characters for identifiers
|
||||
are the same as in Python 2.5; Python 3.0 introduces additional
|
||||
characters from outside the ASCII range (see :pep:`3131`). For other
|
||||
characters, the classification uses the version of the Unicode Character
|
||||
Database as included in the :mod:`unicodedata` module.
|
||||
are the same as in Python 2.x: the uppercase and lowercase letters ``A`` through
|
||||
``Z``, the underscore ``_`` and, except for the first character, the digits
|
||||
``0`` through ``9``.
|
||||
|
||||
Python 3.0 introduces additional characters from outside the ASCII range (see
|
||||
:pep:`3131`). For these characters, the classification uses the version of the
|
||||
Unicode Character Database as included in the :mod:`unicodedata` module.
|
||||
|
||||
Identifiers are unlimited in length. Case is significant.
|
||||
|
||||
|
@ -308,7 +312,6 @@ A non-normative HTML file listing all valid identifier characters for Unicode
|
|||
4.1 can be found at
|
||||
http://www.dcl.hpi.uni-potsdam.de/home/loewis/table-3131.html.
|
||||
|
||||
See :pep:`3131` for further details.
|
||||
|
||||
.. _keywords:
|
||||
|
||||
|
|
|
@ -480,7 +480,7 @@ The :keyword:`raise` statement
|
|||
pair: raising; exception
|
||||
|
||||
.. productionlist::
|
||||
raise_stmt: "raise" [`expression` ["," `expression` ["," `expression`]]]
|
||||
raise_stmt: "raise" [`expression` ["from" `expression`]]
|
||||
|
||||
If no expressions are present, :keyword:`raise` re-raises the last exception
|
||||
that was active in the current scope. If no exception is active in the current
|
||||
|
@ -498,24 +498,20 @@ The :dfn:`type` of the exception is the exception instance's class, the
|
|||
.. index:: object: traceback
|
||||
|
||||
A traceback object is normally created automatically when an exception is raised
|
||||
and attached to it as the :attr:`__traceback__` attribute; however, you can set
|
||||
your own traceback using the :meth:`with_traceback` exception method, like so::
|
||||
and attached to it as the :attr:`__traceback__` attribute, which is writable.
|
||||
You can create an exception and set your own traceback in one step using the
|
||||
:meth:`with_traceback` exception method (which returns the same exception
|
||||
instance, with its traceback set to its argument), like so::
|
||||
|
||||
raise RuntimeError("foo occurred").with_traceback(tracebackobj)
|
||||
|
||||
.. XXX document exception chaining
|
||||
.. XXX document exception chaining
|
||||
|
||||
The "from" clause is used for exception chaining, which is not documented yet.
|
||||
|
||||
Additional information on exceptions can be found in section :ref:`exceptions`,
|
||||
and information about handling exceptions is in section :ref:`try`.
|
||||
|
||||
.. seealso::
|
||||
|
||||
:pep:`3109` - Raising exceptions in Python 3000
|
||||
Describes the differences in :keyword:`raise` statements between Python
|
||||
2.x and 3.0.
|
||||
|
||||
|
||||
.. _break:
|
||||
|
||||
|
|
|
@ -232,7 +232,8 @@ Exception Stuff
|
|||
* PEP 3109: Raising exceptions. You must now use ``raise Exception(args)``
|
||||
instead of ``raise Exception, args``.
|
||||
|
||||
* PEP 3110: Catching exceptions.
|
||||
* PEP 3110: Catching exceptions. You must now use ``except SomeException as
|
||||
identifier:`` instead of ``except Exception, identifier:``
|
||||
|
||||
* PEP 3134: Exception chaining. (The :attr:`__context__` feature from the PEP
|
||||
hasn't been implemented yet in 3.0a2.)
|
||||
|
|
Loading…
Reference in New Issue