mirror of
https://github.com/python/cpython.git
synced 2025-07-31 07:04:42 +00:00
Merged revisions 73941-73943,74076,74094,74186,74211-74214,74247,74254,74262,74311,74334,74368 via svnmerge from
svn+ssh://svn.python.org/python/branches/py3k
................
r73941 | georg.brandl | 2009-07-11 12:39:00 +0200 (Sa, 11 Jul 2009) | 9 lines
Merged revisions 73940 via svnmerge from
svn+ssh://pythondev@svn.python.org/python/trunk
........
r73940 | georg.brandl | 2009-07-11 12:37:38 +0200 (Sa, 11 Jul 2009) | 1 line
#6430: add note about size of "u" type.
........
................
r73942 | georg.brandl | 2009-07-11 12:39:23 +0200 (Sa, 11 Jul 2009) | 1 line
#6430: remove mention of "w" array typecode.
................
r73943 | georg.brandl | 2009-07-11 12:43:08 +0200 (Sa, 11 Jul 2009) | 1 line
#6421: The self argument of module-level PyCFunctions is now a reference to the module object.
................
r74076 | georg.brandl | 2009-07-18 11:07:48 +0200 (Sa, 18 Jul 2009) | 1 line
#6502: add missing comma in docstring.
................
r74094 | georg.brandl | 2009-07-19 09:25:56 +0200 (So, 19 Jul 2009) | 10 lines
Recorded merge of revisions 74089 via svnmerge from
svn+ssh://pythondev@svn.python.org/python/trunk
........
r74089 | senthil.kumaran | 2009-07-19 04:43:43 +0200 (So, 19 Jul 2009) | 3 lines
Fix for issue5102, timeout value propages between redirects, proxy, digest and
auth handlers. Fixed tests to reflect the same.
........
................
r74186 | georg.brandl | 2009-07-23 11:19:09 +0200 (Do, 23 Jul 2009) | 9 lines
Recorded merge of revisions 74185 via svnmerge from
svn+ssh://pythondev@svn.python.org/python/trunk
........
r74185 | georg.brandl | 2009-07-23 11:17:09 +0200 (Do, 23 Jul 2009) | 1 line
Fix the "pylocals" gdb command.
........
................
r74211 | georg.brandl | 2009-07-26 16:48:09 +0200 (So, 26 Jul 2009) | 9 lines
Recorded merge of revisions 74210 via svnmerge from
svn+ssh://pythondev@svn.python.org/python/trunk
........
r74210 | georg.brandl | 2009-07-26 16:44:23 +0200 (So, 26 Jul 2009) | 1 line
Move member descriptions inside the classes.
........
................
r74212 | georg.brandl | 2009-07-26 16:54:51 +0200 (So, 26 Jul 2009) | 9 lines
Merged revisions 74209 via svnmerge from
svn+ssh://pythondev@svn.python.org/python/trunk
........
r74209 | georg.brandl | 2009-07-26 16:37:28 +0200 (So, 26 Jul 2009) | 1 line
builtin -> built-in.
........
................
r74213 | georg.brandl | 2009-07-26 17:02:41 +0200 (So, 26 Jul 2009) | 9 lines
Merged revisions 74207 via svnmerge from
svn+ssh://pythondev@svn.python.org/python/trunk
........
r74207 | georg.brandl | 2009-07-26 16:19:57 +0200 (So, 26 Jul 2009) | 1 line
#6577: fix (hopefully) all links to builtin instead of module/class-specific objects.
........
................
r74214 | georg.brandl | 2009-07-26 17:03:49 +0200 (So, 26 Jul 2009) | 9 lines
Merged revisions 74205 via svnmerge from
svn+ssh://pythondev@svn.python.org/python/trunk
........
r74205 | georg.brandl | 2009-07-26 15:36:39 +0200 (So, 26 Jul 2009) | 1 line
#6576: fix cross-refs in re docs.
........
................
r74247 | georg.brandl | 2009-07-29 09:27:08 +0200 (Mi, 29 Jul 2009) | 9 lines
Merged revisions 74239 via svnmerge from
svn+ssh://pythondev@svn.python.org/python/trunk
........
r74239 | georg.brandl | 2009-07-28 18:55:32 +0000 (Di, 28 Jul 2009) | 1 line
Clarify quote_plus() usage.
........
................
r74254 | georg.brandl | 2009-07-29 18:14:16 +0200 (Mi, 29 Jul 2009) | 1 line
#6586: fix return/argument type doc for os.read() and os.write().
................
r74262 | alexandre.vassalotti | 2009-07-29 21:54:39 +0200 (Mi, 29 Jul 2009) | 57 lines
Merged revisions 74074,74077,74111,74188,74192-74193,74200,74252-74253,74258-74261 via svnmerge from
svn+ssh://pythondev@svn.python.org/python/trunk
........
r74074 | georg.brandl | 2009-07-18 05:03:10 -0400 (Sat, 18 Jul 2009) | 1 line
#6513: fix example code: warning categories are classes, not instances.
........
r74077 | georg.brandl | 2009-07-18 05:43:40 -0400 (Sat, 18 Jul 2009) | 1 line
#6489: fix an ambiguity in getiterator() documentation.
........
r74111 | benjamin.peterson | 2009-07-20 09:30:10 -0400 (Mon, 20 Jul 2009) | 1 line
remove docs for deprecated -p option
........
r74188 | benjamin.peterson | 2009-07-23 10:25:31 -0400 (Thu, 23 Jul 2009) | 1 line
use bools
........
r74192 | georg.brandl | 2009-07-24 12:28:38 -0400 (Fri, 24 Jul 2009) | 1 line
Fix arg types of et#.
........
r74193 | georg.brandl | 2009-07-24 12:46:38 -0400 (Fri, 24 Jul 2009) | 1 line
Dont put "void" in signature for nullary functions.
........
r74200 | georg.brandl | 2009-07-25 09:02:15 -0400 (Sat, 25 Jul 2009) | 1 line
#6571: add index entries for more operators.
........
r74252 | georg.brandl | 2009-07-29 12:06:31 -0400 (Wed, 29 Jul 2009) | 1 line
#6593: fix link targets.
........
r74253 | georg.brandl | 2009-07-29 12:09:17 -0400 (Wed, 29 Jul 2009) | 1 line
#6591: add reference to ioctl in fcntl module for platforms other than Windows.
........
r74258 | georg.brandl | 2009-07-29 12:57:05 -0400 (Wed, 29 Jul 2009) | 1 line
Add a link to readline, and mention IPython and bpython.
........
r74259 | georg.brandl | 2009-07-29 13:07:21 -0400 (Wed, 29 Jul 2009) | 1 line
Fix some markup and small factual glitches found by M. Markert.
........
r74260 | georg.brandl | 2009-07-29 13:15:20 -0400 (Wed, 29 Jul 2009) | 1 line
Fix a few markup glitches.
........
r74261 | georg.brandl | 2009-07-29 13:50:25 -0400 (Wed, 29 Jul 2009) | 1 line
Rewrite the section about classes a bit; mostly tidbits, and a larger update to the section about "private" variables to reflect the Pythonic consensus better.
........
................
r74311 | georg.brandl | 2009-08-04 22:29:27 +0200 (Di, 04 Aug 2009) | 1 line
Slightly improve buffer-related error message.
................
r74334 | georg.brandl | 2009-08-06 19:51:03 +0200 (Do, 06 Aug 2009) | 1 line
#6648: mention surrogateescape handler where all standard handlers are listed.
................
r74368 | georg.brandl | 2009-08-13 09:56:35 +0200 (Do, 13 Aug 2009) | 21 lines
Merged revisions 74328,74332-74333,74365 via svnmerge from
svn+ssh://pythondev@svn.python.org/python/trunk
........
r74328 | georg.brandl | 2009-08-06 17:06:25 +0200 (Do, 06 Aug 2009) | 1 line
Fix base keyword arg name for int() and long().
........
r74332 | georg.brandl | 2009-08-06 19:23:21 +0200 (Do, 06 Aug 2009) | 1 line
Fix punctuation and one copy-paste error.
........
r74333 | georg.brandl | 2009-08-06 19:43:55 +0200 (Do, 06 Aug 2009) | 1 line
#6658: fix two typos.
........
r74365 | georg.brandl | 2009-08-13 09:48:05 +0200 (Do, 13 Aug 2009) | 1 line
#6679: Remove mention that sub supports no flags.
........
................
This commit is contained in:
Georg Brandl
parent
084605518d
commit
c5605dffdb
84 changed files with 536 additions and 535 deletions
|
|
@ -12,44 +12,41 @@ user not to "break into the definition." The most important features of classes
|
|||
are retained with full power, however: the class inheritance mechanism allows
|
||||
multiple base classes, a derived class can override any methods of its base
|
||||
class or classes, and a method can call the method of a base class with the same
|
||||
name. Objects can contain an arbitrary amount of private data.
|
||||
name. Objects can contain an arbitrary amount of data.
|
||||
|
||||
In C++ terminology, normally class members (including the data members) are
|
||||
*public* (except see below :ref:`tut-private`),
|
||||
and all member functions are *virtual*. There are no special constructors or
|
||||
destructors. As in Modula-3, there are no shorthands for referencing the
|
||||
object's members from its methods: the method function is declared with an
|
||||
explicit first argument representing the object, which is provided implicitly by
|
||||
the call. As in Smalltalk, classes themselves are objects, albeit in the wider
|
||||
sense of the word: in Python, all data types are objects. This provides
|
||||
semantics for importing and renaming. Unlike C++ and Modula-3, built-in types
|
||||
can be used as base classes for extension by the user. Also, like in C++ but
|
||||
unlike in Modula-3, most built-in operators with special syntax (arithmetic
|
||||
and all member functions are *virtual*. As in Modula-3, there are no shorthands
|
||||
for referencing the object's members from its methods: the method function is
|
||||
declared with an explicit first argument representing the object, which is
|
||||
provided implicitly by the call. As in Smalltalk, classes themselves are
|
||||
objects. This provides semantics for importing and renaming. Unlike C++ and
|
||||
Modula-3, built-in types can be used as base classes for extension by the user.
|
||||
Also, like in C++, most built-in operators with special syntax (arithmetic
|
||||
operators, subscripting etc.) can be redefined for class instances.
|
||||
|
||||
|
||||
.. _tut-terminology:
|
||||
|
||||
A Word About Terminology
|
||||
========================
|
||||
|
||||
Lacking universally accepted terminology to talk about classes, I will make
|
||||
occasional use of Smalltalk and C++ terms. (I would use Modula-3 terms, since
|
||||
(Lacking universally accepted terminology to talk about classes, I will make
|
||||
occasional use of Smalltalk and C++ terms. I would use Modula-3 terms, since
|
||||
its object-oriented semantics are closer to those of Python than C++, but I
|
||||
expect that few readers have heard of it.)
|
||||
|
||||
|
||||
.. _tut-object:
|
||||
|
||||
A Word About Names and Objects
|
||||
==============================
|
||||
|
||||
Objects have individuality, and multiple names (in multiple scopes) can be bound
|
||||
to the same object. This is known as aliasing in other languages. This is
|
||||
usually not appreciated on a first glance at Python, and can be safely ignored
|
||||
when dealing with immutable basic types (numbers, strings, tuples). However,
|
||||
aliasing has an (intended!) effect on the semantics of Python code involving
|
||||
mutable objects such as lists, dictionaries, and most types representing
|
||||
entities outside the program (files, windows, etc.). This is usually used to
|
||||
the benefit of the program, since aliases behave like pointers in some respects.
|
||||
For example, passing an object is cheap since only a pointer is passed by the
|
||||
implementation; and if a function modifies an object passed as an argument, the
|
||||
caller will see the change --- this eliminates the need for two different
|
||||
argument passing mechanisms as in Pascal.
|
||||
aliasing has a possibly surprising effect on the semantics of Python code
|
||||
involving mutable objects such as lists, dictionaries, and most other types.
|
||||
This is usually used to the benefit of the program, since aliases behave like
|
||||
pointers in some respects. For example, passing an object is cheap since only a
|
||||
pointer is passed by the implementation; and if a function modifies an object
|
||||
passed as an argument, the caller will see the change --- this eliminates the
|
||||
need for two different argument passing mechanisms as in Pascal.
|
||||
|
||||
|
||||
.. _tut-scopes:
|
||||
|
|
@ -73,7 +70,7 @@ built-in exception names); the global names in a module; and the local names in
|
|||
a function invocation. In a sense the set of attributes of an object also form
|
||||
a namespace. The important thing to know about namespaces is that there is
|
||||
absolutely no relation between names in different namespaces; for instance, two
|
||||
different modules may both define a function "maximize" without confusion ---
|
||||
different modules may both define a function ``maximize`` without confusion ---
|
||||
users of the modules must prefix it with the module name.
|
||||
|
||||
By the way, I use the word *attribute* for any name following a dot --- for
|
||||
|
|
@ -112,11 +109,13 @@ name attempts to find the name in the namespace.
|
|||
|
||||
Although scopes are determined statically, they are used dynamically. At any
|
||||
time during execution, there are at least three nested scopes whose namespaces
|
||||
are directly accessible: the innermost scope, which is searched first, contains
|
||||
the local names; the namespaces of any enclosing functions, which are searched
|
||||
starting with the nearest enclosing scope; the middle scope, searched next,
|
||||
contains the current module's global names; and the outermost scope (searched
|
||||
last) is the namespace containing built-in names.
|
||||
are directly accessible:
|
||||
|
||||
* the innermost scope, which is searched first, contains the local names
|
||||
* the scopes of any enclosing functions, which are searched starting with the
|
||||
nearest enclosing scope, contains non-local, but also non-global names
|
||||
* the next-to-last scope contains the current module's global names
|
||||
* the outermost scope (searched last) is the namespace containing built-in names
|
||||
|
||||
If a name is declared global, then all references and assignments go directly to
|
||||
the middle scope containing the module's global names. To rebind variables
|
||||
|
|
@ -138,15 +137,15 @@ language definition is evolving towards static name resolution, at "compile"
|
|||
time, so don't rely on dynamic name resolution! (In fact, local variables are
|
||||
already determined statically.)
|
||||
|
||||
A special quirk of Python is that -- if no :keyword:`global` or
|
||||
:keyword:`nonlocal` statement is in effect -- assignments to names always go
|
||||
into the innermost scope. Assignments do not copy data --- they just bind names
|
||||
to objects. The same is true for deletions: the statement ``del x`` removes the
|
||||
binding of ``x`` from the namespace referenced by the local scope. In fact, all
|
||||
operations that introduce new names use the local scope: in particular, import
|
||||
statements and function definitions bind the module or function name in the
|
||||
local scope. (The :keyword:`global` statement can be used to indicate that
|
||||
particular variables live in the global scope.)
|
||||
A special quirk of Python is that -- if no :keyword:`global` statement is in
|
||||
effect -- assignments to names always go into the innermost scope. Assignments
|
||||
do not copy data --- they just bind names to objects. The same is true for
|
||||
deletions: the statement ``del x`` removes the binding of ``x`` from the
|
||||
namespace referenced by the local scope. In fact, all operations that introduce
|
||||
new names use the local scope: in particular, :keyword:`import` statements and
|
||||
function definitions bind the module or function name in the local scope. (The
|
||||
:keyword:`global` statement can be used to indicate that particular variables
|
||||
live in the global scope.)
|
||||
|
||||
The :keyword:`global` statement can be used to indicate that particular
|
||||
variables live in the global scope and should be rebound there; the
|
||||
|
|
@ -424,9 +423,9 @@ glancing through a method.
|
|||
|
||||
Often, the first argument of a method is called ``self``. This is nothing more
|
||||
than a convention: the name ``self`` has absolutely no special meaning to
|
||||
Python. (Note, however, that by not following the convention your code may be
|
||||
Python. Note, however, that by not following the convention your code may be
|
||||
less readable to other Python programmers, and it is also conceivable that a
|
||||
*class browser* program might be written that relies upon such a convention.)
|
||||
*class browser* program might be written that relies upon such a convention.
|
||||
|
||||
Any function object that is a class attribute defines a method for instances of
|
||||
that class. It is not necessary that the function definition is textually
|
||||
|
|
@ -462,13 +461,13 @@ argument::
|
|||
|
||||
Methods may reference global names in the same way as ordinary functions. The
|
||||
global scope associated with a method is the module containing the class
|
||||
definition. (The class itself is never used as a global scope!) While one
|
||||
definition. (The class itself is never used as a global scope.) While one
|
||||
rarely encounters a good reason for using global data in a method, there are
|
||||
many legitimate uses of the global scope: for one thing, functions and modules
|
||||
imported into the global scope can be used by methods, as well as functions and
|
||||
classes defined in it. Usually, the class containing the method is itself
|
||||
defined in this global scope, and in the next section we'll find some good
|
||||
reasons why a method would want to reference its own class!
|
||||
reasons why a method would want to reference its own class.
|
||||
|
||||
Each value is an object, and therefore has a *class* (also called its *type*).
|
||||
It is stored as ``object.__class__``.
|
||||
|
|
@ -519,12 +518,12 @@ An overriding method in a derived class may in fact want to extend rather than
|
|||
simply replace the base class method of the same name. There is a simple way to
|
||||
call the base class method directly: just call ``BaseClassName.methodname(self,
|
||||
arguments)``. This is occasionally useful to clients as well. (Note that this
|
||||
only works if the base class is defined or imported directly in the global
|
||||
only works if the base class is accessible as ``BaseClassName`` in the global
|
||||
scope.)
|
||||
|
||||
Python has two built-in functions that work with inheritance:
|
||||
|
||||
* Use :func:`isinstance` to check an object's type: ``isinstance(obj, int)``
|
||||
* Use :func:`isinstance` to check an instance's type: ``isinstance(obj, int)``
|
||||
will be ``True`` only if ``obj.__class__`` is :class:`int` or some class
|
||||
derived from :class:`int`.
|
||||
|
||||
|
|
@ -582,28 +581,30 @@ http://www.python.org/download/releases/2.3/mro/.
|
|||
Private Variables
|
||||
=================
|
||||
|
||||
There is limited support for class-private identifiers. Any identifier of the
|
||||
form ``__spam`` (at least two leading underscores, at most one trailing
|
||||
underscore) is textually replaced with ``_classname__spam``, where ``classname``
|
||||
is the current class name with leading underscore(s) stripped. This mangling is
|
||||
done without regard to the syntactic position of the identifier, so it can be
|
||||
used to define class-private instance and class variables, methods, variables
|
||||
stored in globals, and even variables stored in instances. private to this class
|
||||
on instances of *other* classes. Truncation may occur when the mangled name
|
||||
would be longer than 255 characters. Outside classes, or when the class name
|
||||
consists of only underscores, no mangling occurs.
|
||||
"Private" instance variables that cannot be accessed except from inside an
|
||||
object, don't exist in Python. However, there is a convention that is followed
|
||||
by most Python code: a name prefixed with an underscore (e.g. ``_spam``) should
|
||||
be treated as a non-public part of the API (whether it is a function, a method
|
||||
or a data member). It should be considered an implementation detail and subject
|
||||
to change without notice.
|
||||
|
||||
Name mangling is intended to give classes an easy way to define "private"
|
||||
instance variables and methods, without having to worry about instance variables
|
||||
defined by derived classes, or mucking with instance variables by code outside
|
||||
the class. Note that the mangling rules are designed mostly to avoid accidents;
|
||||
it still is possible for a determined soul to access or modify a variable that
|
||||
is considered private. This can even be useful in special circumstances, such
|
||||
as in the debugger, and that's one reason why this loophole is not closed.
|
||||
(Buglet: derivation of a class with the same name as the base class makes use of
|
||||
private variables of the base class possible.)
|
||||
Since there is a valid use-case for class-private members (namely to avoid name
|
||||
clashes of names with names defined by subclasses), there is limited support for
|
||||
such a mechanism, called :dfn:`name mangling`. Any identifier of the form
|
||||
``__spam`` (at least two leading underscores, at most one trailing underscore)
|
||||
is textually replaced with ``_classname__spam``, where ``classname`` is the
|
||||
current class name with leading underscore(s) stripped. This mangling is done
|
||||
without regard to the syntactic position of the identifier, so it can be used to
|
||||
define class-private instance and class variables, methods, variables stored in
|
||||
globals, and even variables stored in instances. Truncation may occur when the
|
||||
mangled name would be longer than 255 characters. Outside classes, or when the
|
||||
class name consists of only underscores, no mangling occurs.
|
||||
|
||||
Notice that code passed to ``exec()`` or ``eval()`` does not
|
||||
Note that the mangling rules are designed mostly to avoid accidents; it still is
|
||||
possible to access or modify a variable that is considered private. This can
|
||||
even be useful in special circumstances, such as in the debugger.
|
||||
|
||||
Notice that code passed to ``exec()``, ``eval()`` or ``execfile()`` does not
|
||||
consider the classname of the invoking class to be the current class; this is
|
||||
similar to the effect of the ``global`` statement, the effect of which is
|
||||
likewise restricted to code that is byte-compiled together. The same
|
||||
|
|
@ -654,7 +655,7 @@ Exceptions Are Classes Too
|
|||
User-defined exceptions are identified by classes as well. Using this mechanism
|
||||
it is possible to create extensible hierarchies of exceptions.
|
||||
|
||||
There are two valid (semantic) forms for the raise statement::
|
||||
There are two new valid (semantic) forms for the :keyword:`raise` statement::
|
||||
|
||||
raise Class
|
||||
|
||||
|
|
@ -665,10 +666,10 @@ class derived from it. The first form is a shorthand for::
|
|||
|
||||
raise Class()
|
||||
|
||||
A class in an except clause is compatible with an exception if it is the same
|
||||
class or a base class thereof (but not the other way around --- an except clause
|
||||
listing a derived class is not compatible with a base class). For example, the
|
||||
following code will print B, C, D in that order::
|
||||
A class in an :keyword:`except` clause is compatible with an exception if it is
|
||||
the same class or a base class thereof (but not the other way around --- an
|
||||
except clause listing a derived class is not compatible with a base class). For
|
||||
example, the following code will print B, C, D in that order::
|
||||
|
||||
class B(Exception):
|
||||
pass
|
||||
|
|
|
|||
Loading…
Add table
Add a link
Reference in a new issue