blob: 7ea6ca757a905f3cd298533595e8ebfbf9d1cbae [file] [log] [blame]
Georg Brandl8ec7f652007-08-15 14:28:01 +00001
2.. _datamodel:
3
4**********
5Data model
6**********
7
8
9.. _objects:
10
11Objects, values and types
12=========================
13
14.. index::
15 single: object
16 single: data
17
18:dfn:`Objects` are Python's abstraction for data. All data in a Python program
19is represented by objects or by relations between objects. (In a sense, and in
20conformance to Von Neumann's model of a "stored program computer," code is also
21represented by objects.)
22
23.. index::
24 builtin: id
25 builtin: type
26 single: identity of an object
27 single: value of an object
28 single: type of an object
29 single: mutable object
30 single: immutable object
31
32Every object has an identity, a type and a value. An object's *identity* never
33changes once it has been created; you may think of it as the object's address in
34memory. The ':keyword:`is`' operator compares the identity of two objects; the
35:func:`id` function returns an integer representing its identity (currently
36implemented as its address). An object's :dfn:`type` is also unchangeable. [#]_
37An object's type determines the operations that the object supports (e.g., "does
38it have a length?") and also defines the possible values for objects of that
39type. The :func:`type` function returns an object's type (which is an object
40itself). The *value* of some objects can change. Objects whose value can
41change are said to be *mutable*; objects whose value is unchangeable once they
42are created are called *immutable*. (The value of an immutable container object
43that contains a reference to a mutable object can change when the latter's value
44is changed; however the container is still considered immutable, because the
45collection of objects it contains cannot be changed. So, immutability is not
46strictly the same as having an unchangeable value, it is more subtle.) An
47object's mutability is determined by its type; for instance, numbers, strings
48and tuples are immutable, while dictionaries and lists are mutable.
49
50.. index::
51 single: garbage collection
52 single: reference counting
53 single: unreachable object
54
55Objects are never explicitly destroyed; however, when they become unreachable
56they may be garbage-collected. An implementation is allowed to postpone garbage
57collection or omit it altogether --- it is a matter of implementation quality
58how garbage collection is implemented, as long as no objects are collected that
59are still reachable. (Implementation note: the current implementation uses a
60reference-counting scheme with (optional) delayed detection of cyclically linked
61garbage, which collects most objects as soon as they become unreachable, but is
62not guaranteed to collect garbage containing circular references. See the
63documentation of the :mod:`gc` module for information on controlling the
64collection of cyclic garbage.)
65
66Note that the use of the implementation's tracing or debugging facilities may
67keep objects alive that would normally be collectable. Also note that catching
68an exception with a ':keyword:`try`...\ :keyword:`except`' statement may keep
69objects alive.
70
71Some objects contain references to "external" resources such as open files or
72windows. It is understood that these resources are freed when the object is
73garbage-collected, but since garbage collection is not guaranteed to happen,
74such objects also provide an explicit way to release the external resource,
75usually a :meth:`close` method. Programs are strongly recommended to explicitly
76close such objects. The ':keyword:`try`...\ :keyword:`finally`' statement
77provides a convenient way to do this.
78
79.. index:: single: container
80
81Some objects contain references to other objects; these are called *containers*.
82Examples of containers are tuples, lists and dictionaries. The references are
83part of a container's value. In most cases, when we talk about the value of a
84container, we imply the values, not the identities of the contained objects;
85however, when we talk about the mutability of a container, only the identities
86of the immediately contained objects are implied. So, if an immutable container
87(like a tuple) contains a reference to a mutable object, its value changes if
88that mutable object is changed.
89
90Types affect almost all aspects of object behavior. Even the importance of
91object identity is affected in some sense: for immutable types, operations that
92compute new values may actually return a reference to any existing object with
93the same type and value, while for mutable objects this is not allowed. E.g.,
94after ``a = 1; b = 1``, ``a`` and ``b`` may or may not refer to the same object
95with the value one, depending on the implementation, but after ``c = []; d =
96[]``, ``c`` and ``d`` are guaranteed to refer to two different, unique, newly
97created empty lists. (Note that ``c = d = []`` assigns the same object to both
98``c`` and ``d``.)
99
100
101.. _types:
102
103The standard type hierarchy
104===========================
105
106.. index::
107 single: type
108 pair: data; type
109 pair: type; hierarchy
110 pair: extension; module
111 pair: C; language
112
113Below is a list of the types that are built into Python. Extension modules
114(written in C, Java, or other languages, depending on the implementation) can
115define additional types. Future versions of Python may add types to the type
116hierarchy (e.g., rational numbers, efficiently stored arrays of integers, etc.).
117
118.. index::
119 single: attribute
120 pair: special; attribute
121 triple: generic; special; attribute
122
123Some of the type descriptions below contain a paragraph listing 'special
124attributes.' These are attributes that provide access to the implementation and
125are not intended for general use. Their definition may change in the future.
126
127None
128 .. index:: object: None
129
130 This type has a single value. There is a single object with this value. This
131 object is accessed through the built-in name ``None``. It is used to signify the
132 absence of a value in many situations, e.g., it is returned from functions that
133 don't explicitly return anything. Its truth value is false.
134
135NotImplemented
136 .. index:: object: NotImplemented
137
138 This type has a single value. There is a single object with this value. This
139 object is accessed through the built-in name ``NotImplemented``. Numeric methods
140 and rich comparison methods may return this value if they do not implement the
141 operation for the operands provided. (The interpreter will then try the
142 reflected operation, or some other fallback, depending on the operator.) Its
143 truth value is true.
144
145Ellipsis
146 .. index:: object: Ellipsis
147
148 This type has a single value. There is a single object with this value. This
149 object is accessed through the built-in name ``Ellipsis``. It is used to
150 indicate the presence of the ``...`` syntax in a slice. Its truth value is
151 true.
152
Jeffrey Yasskin2f3c16b2008-01-03 02:21:52 +0000153:class:`numbers.Number`
Georg Brandl8ec7f652007-08-15 14:28:01 +0000154 .. index:: object: numeric
155
156 These are created by numeric literals and returned as results by arithmetic
157 operators and arithmetic built-in functions. Numeric objects are immutable;
158 once created their value never changes. Python numbers are of course strongly
159 related to mathematical numbers, but subject to the limitations of numerical
160 representation in computers.
161
162 Python distinguishes between integers, floating point numbers, and complex
163 numbers:
164
Jeffrey Yasskin2f3c16b2008-01-03 02:21:52 +0000165 :class:`numbers.Integral`
Georg Brandl8ec7f652007-08-15 14:28:01 +0000166 .. index:: object: integer
167
168 These represent elements from the mathematical set of integers (positive and
169 negative).
170
171 There are three types of integers:
172
173 Plain integers
174 .. index::
175 object: plain integer
176 single: OverflowError (built-in exception)
177
178 These represent numbers in the range -2147483648 through 2147483647. (The range
179 may be larger on machines with a larger natural word size, but not smaller.)
180 When the result of an operation would fall outside this range, the result is
181 normally returned as a long integer (in some cases, the exception
182 :exc:`OverflowError` is raised instead). For the purpose of shift and mask
183 operations, integers are assumed to have a binary, 2's complement notation using
184 32 or more bits, and hiding no bits from the user (i.e., all 4294967296
185 different bit patterns correspond to different values).
186
187 Long integers
188 .. index:: object: long integer
189
190 These represent numbers in an unlimited range, subject to available (virtual)
191 memory only. For the purpose of shift and mask operations, a binary
192 representation is assumed, and negative numbers are represented in a variant of
193 2's complement which gives the illusion of an infinite string of sign bits
194 extending to the left.
195
196 Booleans
197 .. index::
198 object: Boolean
199 single: False
200 single: True
201
202 These represent the truth values False and True. The two objects representing
203 the values False and True are the only Boolean objects. The Boolean type is a
204 subtype of plain integers, and Boolean values behave like the values 0 and 1,
205 respectively, in almost all contexts, the exception being that when converted to
206 a string, the strings ``"False"`` or ``"True"`` are returned, respectively.
207
208 .. index:: pair: integer; representation
209
210 The rules for integer representation are intended to give the most meaningful
211 interpretation of shift and mask operations involving negative integers and the
212 least surprises when switching between the plain and long integer domains. Any
213 operation except left shift, if it yields a result in the plain integer domain
214 without causing overflow, will yield the same result in the long integer domain
215 or when using mixed operands.
216
Jeffrey Yasskin2f3c16b2008-01-03 02:21:52 +0000217 :class:`numbers.Real` (:class:`float`)
Georg Brandl8ec7f652007-08-15 14:28:01 +0000218 .. index::
219 object: floating point
220 pair: floating point; number
221 pair: C; language
222 pair: Java; language
223
224 These represent machine-level double precision floating point numbers. You are
225 at the mercy of the underlying machine architecture (and C or Java
226 implementation) for the accepted range and handling of overflow. Python does not
227 support single-precision floating point numbers; the savings in processor and
228 memory usage that are usually the reason for using these is dwarfed by the
229 overhead of using objects in Python, so there is no reason to complicate the
230 language with two kinds of floating point numbers.
231
Jeffrey Yasskin2f3c16b2008-01-03 02:21:52 +0000232 :class:`numbers.Complex`
Georg Brandl8ec7f652007-08-15 14:28:01 +0000233 .. index::
234 object: complex
235 pair: complex; number
236
237 These represent complex numbers as a pair of machine-level double precision
238 floating point numbers. The same caveats apply as for floating point numbers.
239 The real and imaginary parts of a complex number ``z`` can be retrieved through
240 the read-only attributes ``z.real`` and ``z.imag``.
241
Georg Brandl8ec7f652007-08-15 14:28:01 +0000242Sequences
243 .. index::
244 builtin: len
245 object: sequence
246 single: index operation
247 single: item selection
248 single: subscription
249
250 These represent finite ordered sets indexed by non-negative numbers. The
251 built-in function :func:`len` returns the number of items of a sequence. When
252 the length of a sequence is *n*, the index set contains the numbers 0, 1,
253 ..., *n*-1. Item *i* of sequence *a* is selected by ``a[i]``.
254
255 .. index:: single: slicing
256
257 Sequences also support slicing: ``a[i:j]`` selects all items with index *k* such
258 that *i* ``<=`` *k* ``<`` *j*. When used as an expression, a slice is a
259 sequence of the same type. This implies that the index set is renumbered so
260 that it starts at 0.
261
262 .. index:: single: extended slicing
263
264 Some sequences also support "extended slicing" with a third "step" parameter:
265 ``a[i:j:k]`` selects all items of *a* with index *x* where ``x = i + n*k``, *n*
266 ``>=`` ``0`` and *i* ``<=`` *x* ``<`` *j*.
267
268 Sequences are distinguished according to their mutability:
269
270 Immutable sequences
271 .. index::
272 object: immutable sequence
273 object: immutable
274
275 An object of an immutable sequence type cannot change once it is created. (If
276 the object contains references to other objects, these other objects may be
277 mutable and may be changed; however, the collection of objects directly
278 referenced by an immutable object cannot change.)
279
280 The following types are immutable sequences:
281
282 Strings
283 .. index::
284 builtin: chr
285 builtin: ord
286 object: string
287 single: character
288 single: byte
289 single: ASCII@ASCII
290
291 The items of a string are characters. There is no separate character type; a
292 character is represented by a string of one item. Characters represent (at
293 least) 8-bit bytes. The built-in functions :func:`chr` and :func:`ord` convert
294 between characters and nonnegative integers representing the byte values. Bytes
295 with the values 0-127 usually represent the corresponding ASCII values, but the
296 interpretation of values is up to the program. The string data type is also
297 used to represent arrays of bytes, e.g., to hold data read from a file.
298
299 .. index::
300 single: ASCII@ASCII
301 single: EBCDIC
302 single: character set
303 pair: string; comparison
304 builtin: chr
305 builtin: ord
306
307 (On systems whose native character set is not ASCII, strings may use EBCDIC in
308 their internal representation, provided the functions :func:`chr` and
309 :func:`ord` implement a mapping between ASCII and EBCDIC, and string comparison
310 preserves the ASCII order. Or perhaps someone can propose a better rule?)
311
312 Unicode
313 .. index::
314 builtin: unichr
315 builtin: ord
316 builtin: unicode
317 object: unicode
318 single: character
319 single: integer
320 single: Unicode
321
322 The items of a Unicode object are Unicode code units. A Unicode code unit is
323 represented by a Unicode object of one item and can hold either a 16-bit or
324 32-bit value representing a Unicode ordinal (the maximum value for the ordinal
325 is given in ``sys.maxunicode``, and depends on how Python is configured at
326 compile time). Surrogate pairs may be present in the Unicode object, and will
327 be reported as two separate items. The built-in functions :func:`unichr` and
328 :func:`ord` convert between code units and nonnegative integers representing the
329 Unicode ordinals as defined in the Unicode Standard 3.0. Conversion from and to
330 other encodings are possible through the Unicode method :meth:`encode` and the
331 built-in function :func:`unicode`.
332
333 Tuples
334 .. index::
335 object: tuple
336 pair: singleton; tuple
337 pair: empty; tuple
338
339 The items of a tuple are arbitrary Python objects. Tuples of two or more items
340 are formed by comma-separated lists of expressions. A tuple of one item (a
341 'singleton') can be formed by affixing a comma to an expression (an expression
342 by itself does not create a tuple, since parentheses must be usable for grouping
343 of expressions). An empty tuple can be formed by an empty pair of parentheses.
344
Georg Brandl8ec7f652007-08-15 14:28:01 +0000345 Mutable sequences
346 .. index::
347 object: mutable sequence
348 object: mutable
349 pair: assignment; statement
350 single: delete
351 statement: del
352 single: subscription
353 single: slicing
354
355 Mutable sequences can be changed after they are created. The subscription and
356 slicing notations can be used as the target of assignment and :keyword:`del`
357 (delete) statements.
358
359 There is currently a single intrinsic mutable sequence type:
360
361 Lists
362 .. index:: object: list
363
364 The items of a list are arbitrary Python objects. Lists are formed by placing a
365 comma-separated list of expressions in square brackets. (Note that there are no
366 special cases needed to form lists of length 0 or 1.)
367
368 .. index:: module: array
369
370 The extension module :mod:`array` provides an additional example of a mutable
371 sequence type.
372
Georg Brandl8ec7f652007-08-15 14:28:01 +0000373Set types
374 .. index::
375 builtin: len
376 object: set type
377
378 These represent unordered, finite sets of unique, immutable objects. As such,
379 they cannot be indexed by any subscript. However, they can be iterated over, and
380 the built-in function :func:`len` returns the number of items in a set. Common
381 uses for sets are fast membership testing, removing duplicates from a sequence,
382 and computing mathematical operations such as intersection, union, difference,
383 and symmetric difference.
384
385 For set elements, the same immutability rules apply as for dictionary keys. Note
386 that numeric types obey the normal rules for numeric comparison: if two numbers
387 compare equal (e.g., ``1`` and ``1.0``), only one of them can be contained in a
388 set.
389
390 There are currently two intrinsic set types:
391
392 Sets
393 .. index:: object: set
394
395 These represent a mutable set. They are created by the built-in :func:`set`
396 constructor and can be modified afterwards by several methods, such as
397 :meth:`add`.
398
399 Frozen sets
400 .. index:: object: frozenset
401
Georg Brandl7c3e79f2007-11-02 20:06:17 +0000402 These represent an immutable set. They are created by the built-in
403 :func:`frozenset` constructor. As a frozenset is immutable and
404 :term:`hashable`, it can be used again as an element of another set, or as
405 a dictionary key.
Georg Brandl8ec7f652007-08-15 14:28:01 +0000406
Georg Brandl8ec7f652007-08-15 14:28:01 +0000407Mappings
408 .. index::
409 builtin: len
410 single: subscription
411 object: mapping
412
413 These represent finite sets of objects indexed by arbitrary index sets. The
414 subscript notation ``a[k]`` selects the item indexed by ``k`` from the mapping
415 ``a``; this can be used in expressions and as the target of assignments or
416 :keyword:`del` statements. The built-in function :func:`len` returns the number
417 of items in a mapping.
418
419 There is currently a single intrinsic mapping type:
420
421 Dictionaries
422 .. index:: object: dictionary
423
424 These represent finite sets of objects indexed by nearly arbitrary values. The
425 only types of values not acceptable as keys are values containing lists or
426 dictionaries or other mutable types that are compared by value rather than by
427 object identity, the reason being that the efficient implementation of
428 dictionaries requires a key's hash value to remain constant. Numeric types used
429 for keys obey the normal rules for numeric comparison: if two numbers compare
430 equal (e.g., ``1`` and ``1.0``) then they can be used interchangeably to index
431 the same dictionary entry.
432
433 Dictionaries are mutable; they can be created by the ``{...}`` notation (see
434 section :ref:`dict`).
435
436 .. index::
437 module: dbm
438 module: gdbm
439 module: bsddb
440
441 The extension modules :mod:`dbm`, :mod:`gdbm`, and :mod:`bsddb` provide
442 additional examples of mapping types.
443
Georg Brandl8ec7f652007-08-15 14:28:01 +0000444Callable types
445 .. index::
446 object: callable
447 pair: function; call
448 single: invocation
449 pair: function; argument
450
451 These are the types to which the function call operation (see section
452 :ref:`calls`) can be applied:
453
454 User-defined functions
455 .. index::
456 pair: user-defined; function
457 object: function
458 object: user-defined function
459
460 A user-defined function object is created by a function definition (see
461 section :ref:`function`). It should be called with an argument list
462 containing the same number of items as the function's formal parameter
463 list.
464
465 Special attributes:
466
467 +-----------------------+-------------------------------+-----------+
468 | Attribute | Meaning | |
469 +=======================+===============================+===========+
470 | :attr:`func_doc` | The function's documentation | Writable |
471 | | string, or ``None`` if | |
472 | | unavailable | |
473 +-----------------------+-------------------------------+-----------+
474 | :attr:`__doc__` | Another way of spelling | Writable |
475 | | :attr:`func_doc` | |
476 +-----------------------+-------------------------------+-----------+
477 | :attr:`func_name` | The function's name | Writable |
478 +-----------------------+-------------------------------+-----------+
479 | :attr:`__name__` | Another way of spelling | Writable |
480 | | :attr:`func_name` | |
481 +-----------------------+-------------------------------+-----------+
482 | :attr:`__module__` | The name of the module the | Writable |
483 | | function was defined in, or | |
484 | | ``None`` if unavailable. | |
485 +-----------------------+-------------------------------+-----------+
486 | :attr:`func_defaults` | A tuple containing default | Writable |
487 | | argument values for those | |
488 | | arguments that have defaults, | |
489 | | or ``None`` if no arguments | |
490 | | have a default value | |
491 +-----------------------+-------------------------------+-----------+
492 | :attr:`func_code` | The code object representing | Writable |
493 | | the compiled function body. | |
494 +-----------------------+-------------------------------+-----------+
495 | :attr:`func_globals` | A reference to the dictionary | Read-only |
496 | | that holds the function's | |
497 | | global variables --- the | |
498 | | global namespace of the | |
499 | | module in which the function | |
500 | | was defined. | |
501 +-----------------------+-------------------------------+-----------+
502 | :attr:`func_dict` | The namespace supporting | Writable |
503 | | arbitrary function | |
504 | | attributes. | |
505 +-----------------------+-------------------------------+-----------+
506 | :attr:`func_closure` | ``None`` or a tuple of cells | Read-only |
507 | | that contain bindings for the | |
508 | | function's free variables. | |
509 +-----------------------+-------------------------------+-----------+
510
511 Most of the attributes labelled "Writable" check the type of the assigned value.
512
513 .. versionchanged:: 2.4
514 ``func_name`` is now writable.
515
516 Function objects also support getting and setting arbitrary attributes, which
517 can be used, for example, to attach metadata to functions. Regular attribute
518 dot-notation is used to get and set such attributes. *Note that the current
519 implementation only supports function attributes on user-defined functions.
520 Function attributes on built-in functions may be supported in the future.*
521
522 Additional information about a function's definition can be retrieved from its
523 code object; see the description of internal types below.
524
525 .. index::
526 single: func_doc (function attribute)
527 single: __doc__ (function attribute)
528 single: __name__ (function attribute)
529 single: __module__ (function attribute)
530 single: __dict__ (function attribute)
531 single: func_defaults (function attribute)
532 single: func_closure (function attribute)
533 single: func_code (function attribute)
534 single: func_globals (function attribute)
535 single: func_dict (function attribute)
536 pair: global; namespace
537
538 User-defined methods
539 .. index::
540 object: method
541 object: user-defined method
542 pair: user-defined; method
543
544 A user-defined method object combines a class, a class instance (or ``None``)
545 and any callable object (normally a user-defined function).
546
547 Special read-only attributes: :attr:`im_self` is the class instance object,
548 :attr:`im_func` is the function object; :attr:`im_class` is the class of
549 :attr:`im_self` for bound methods or the class that asked for the method for
550 unbound methods; :attr:`__doc__` is the method's documentation (same as
551 ``im_func.__doc__``); :attr:`__name__` is the method name (same as
552 ``im_func.__name__``); :attr:`__module__` is the name of the module the method
553 was defined in, or ``None`` if unavailable.
554
555 .. versionchanged:: 2.2
556 :attr:`im_self` used to refer to the class that defined the method.
557
558 .. index::
559 single: __doc__ (method attribute)
560 single: __name__ (method attribute)
561 single: __module__ (method attribute)
562 single: im_func (method attribute)
563 single: im_self (method attribute)
564
565 Methods also support accessing (but not setting) the arbitrary function
566 attributes on the underlying function object.
567
568 User-defined method objects may be created when getting an attribute of a class
569 (perhaps via an instance of that class), if that attribute is a user-defined
570 function object, an unbound user-defined method object, or a class method
571 object. When the attribute is a user-defined method object, a new method object
572 is only created if the class from which it is being retrieved is the same as, or
573 a derived class of, the class stored in the original method object; otherwise,
574 the original method object is used as it is.
575
576 .. index::
577 single: im_class (method attribute)
578 single: im_func (method attribute)
579 single: im_self (method attribute)
580
581 When a user-defined method object is created by retrieving a user-defined
582 function object from a class, its :attr:`im_self` attribute is ``None``
583 and the method object is said to be unbound. When one is created by
584 retrieving a user-defined function object from a class via one of its
585 instances, its :attr:`im_self` attribute is the instance, and the method
586 object is said to be bound. In either case, the new method's
587 :attr:`im_class` attribute is the class from which the retrieval takes
588 place, and its :attr:`im_func` attribute is the original function object.
589
590 .. index:: single: im_func (method attribute)
591
592 When a user-defined method object is created by retrieving another method object
593 from a class or instance, the behaviour is the same as for a function object,
594 except that the :attr:`im_func` attribute of the new instance is not the
595 original method object but its :attr:`im_func` attribute.
596
597 .. index::
598 single: im_class (method attribute)
599 single: im_func (method attribute)
600 single: im_self (method attribute)
601
602 When a user-defined method object is created by retrieving a class method object
603 from a class or instance, its :attr:`im_self` attribute is the class itself (the
604 same as the :attr:`im_class` attribute), and its :attr:`im_func` attribute is
605 the function object underlying the class method.
606
607 When an unbound user-defined method object is called, the underlying function
608 (:attr:`im_func`) is called, with the restriction that the first argument must
609 be an instance of the proper class (:attr:`im_class`) or of a derived class
610 thereof.
611
612 When a bound user-defined method object is called, the underlying function
613 (:attr:`im_func`) is called, inserting the class instance (:attr:`im_self`) in
614 front of the argument list. For instance, when :class:`C` is a class which
615 contains a definition for a function :meth:`f`, and ``x`` is an instance of
616 :class:`C`, calling ``x.f(1)`` is equivalent to calling ``C.f(x, 1)``.
617
618 When a user-defined method object is derived from a class method object, the
619 "class instance" stored in :attr:`im_self` will actually be the class itself, so
620 that calling either ``x.f(1)`` or ``C.f(1)`` is equivalent to calling ``f(C,1)``
621 where ``f`` is the underlying function.
622
623 Note that the transformation from function object to (unbound or bound) method
624 object happens each time the attribute is retrieved from the class or instance.
625 In some cases, a fruitful optimization is to assign the attribute to a local
626 variable and call that local variable. Also notice that this transformation only
627 happens for user-defined functions; other callable objects (and all non-callable
628 objects) are retrieved without transformation. It is also important to note
629 that user-defined functions which are attributes of a class instance are not
630 converted to bound methods; this *only* happens when the function is an
631 attribute of the class.
632
633 Generator functions
634 .. index::
635 single: generator; function
636 single: generator; iterator
637
638 A function or method which uses the :keyword:`yield` statement (see section
639 :ref:`yield`) is called a :dfn:`generator
640 function`. Such a function, when called, always returns an iterator object
641 which can be used to execute the body of the function: calling the iterator's
642 :meth:`next` method will cause the function to execute until it provides a value
643 using the :keyword:`yield` statement. When the function executes a
644 :keyword:`return` statement or falls off the end, a :exc:`StopIteration`
645 exception is raised and the iterator will have reached the end of the set of
646 values to be returned.
647
648 Built-in functions
649 .. index::
650 object: built-in function
651 object: function
652 pair: C; language
653
654 A built-in function object is a wrapper around a C function. Examples of
655 built-in functions are :func:`len` and :func:`math.sin` (:mod:`math` is a
656 standard built-in module). The number and type of the arguments are
657 determined by the C function. Special read-only attributes:
658 :attr:`__doc__` is the function's documentation string, or ``None`` if
659 unavailable; :attr:`__name__` is the function's name; :attr:`__self__` is
660 set to ``None`` (but see the next item); :attr:`__module__` is the name of
661 the module the function was defined in or ``None`` if unavailable.
662
663 Built-in methods
664 .. index::
665 object: built-in method
666 object: method
667 pair: built-in; method
668
669 This is really a different disguise of a built-in function, this time containing
670 an object passed to the C function as an implicit extra argument. An example of
671 a built-in method is ``alist.append()``, assuming *alist* is a list object. In
672 this case, the special read-only attribute :attr:`__self__` is set to the object
673 denoted by *list*.
674
675 Class Types
676 Class types, or "new-style classes," are callable. These objects normally act
677 as factories for new instances of themselves, but variations are possible for
678 class types that override :meth:`__new__`. The arguments of the call are passed
679 to :meth:`__new__` and, in the typical case, to :meth:`__init__` to initialize
680 the new instance.
681
682 Classic Classes
683 .. index::
684 single: __init__() (object method)
685 object: class
686 object: class instance
687 object: instance
688 pair: class object; call
689
690 Class objects are described below. When a class object is called, a new class
691 instance (also described below) is created and returned. This implies a call to
692 the class's :meth:`__init__` method if it has one. Any arguments are passed on
693 to the :meth:`__init__` method. If there is no :meth:`__init__` method, the
694 class must be called without arguments.
695
696 Class instances
697 Class instances are described below. Class instances are callable only when the
698 class has a :meth:`__call__` method; ``x(arguments)`` is a shorthand for
699 ``x.__call__(arguments)``.
700
701Modules
702 .. index::
703 statement: import
704 object: module
705
706 Modules are imported by the :keyword:`import` statement (see section
707 :ref:`import`). A module object has a
708 namespace implemented by a dictionary object (this is the dictionary referenced
709 by the func_globals attribute of functions defined in the module). Attribute
710 references are translated to lookups in this dictionary, e.g., ``m.x`` is
711 equivalent to ``m.__dict__["x"]``. A module object does not contain the code
712 object used to initialize the module (since it isn't needed once the
713 initialization is done).
714
Georg Brandl8ec7f652007-08-15 14:28:01 +0000715 Attribute assignment updates the module's namespace dictionary, e.g., ``m.x =
716 1`` is equivalent to ``m.__dict__["x"] = 1``.
717
718 .. index:: single: __dict__ (module attribute)
719
720 Special read-only attribute: :attr:`__dict__` is the module's namespace as a
721 dictionary object.
722
723 .. index::
724 single: __name__ (module attribute)
725 single: __doc__ (module attribute)
726 single: __file__ (module attribute)
727 pair: module; namespace
728
729 Predefined (writable) attributes: :attr:`__name__` is the module's name;
730 :attr:`__doc__` is the module's documentation string, or ``None`` if
731 unavailable; :attr:`__file__` is the pathname of the file from which the module
732 was loaded, if it was loaded from a file. The :attr:`__file__` attribute is not
733 present for C modules that are statically linked into the interpreter; for
734 extension modules loaded dynamically from a shared library, it is the pathname
735 of the shared library file.
736
737Classes
738 Class objects are created by class definitions (see section :ref:`class`). A
739 class has a namespace implemented by a dictionary object. Class attribute
740 references are translated to lookups in this dictionary, e.g., ``C.x`` is
741 translated to ``C.__dict__["x"]``. When the attribute name is not found
742 there, the attribute search continues in the base classes. The search is
743 depth-first, left-to-right in the order of occurrence in the base class list.
744
745 .. index::
746 object: class
747 object: class instance
748 object: instance
749 pair: class object; call
750 single: container
751 object: dictionary
752 pair: class; attribute
753
754 When a class attribute reference (for class :class:`C`, say) would yield a
755 user-defined function object or an unbound user-defined method object whose
756 associated class is either :class:`C` or one of its base classes, it is
757 transformed into an unbound user-defined method object whose :attr:`im_class`
758 attribute is :class:`C`. When it would yield a class method object, it is
759 transformed into a bound user-defined method object whose :attr:`im_class`
760 and :attr:`im_self` attributes are both :class:`C`. When it would yield a
761 static method object, it is transformed into the object wrapped by the static
762 method object. See section :ref:`descriptors` for another way in which
763 attributes retrieved from a class may differ from those actually contained in
764 its :attr:`__dict__`.
765
766 .. index:: triple: class; attribute; assignment
767
768 Class attribute assignments update the class's dictionary, never the dictionary
769 of a base class.
770
771 .. index:: pair: class object; call
772
773 A class object can be called (see above) to yield a class instance (see below).
774
775 .. index::
776 single: __name__ (class attribute)
777 single: __module__ (class attribute)
778 single: __dict__ (class attribute)
779 single: __bases__ (class attribute)
780 single: __doc__ (class attribute)
781
782 Special attributes: :attr:`__name__` is the class name; :attr:`__module__` is
783 the module name in which the class was defined; :attr:`__dict__` is the
784 dictionary containing the class's namespace; :attr:`__bases__` is a tuple
785 (possibly empty or a singleton) containing the base classes, in the order of
786 their occurrence in the base class list; :attr:`__doc__` is the class's
787 documentation string, or None if undefined.
788
789Class instances
790 .. index::
791 object: class instance
792 object: instance
793 pair: class; instance
794 pair: class instance; attribute
795
796 A class instance is created by calling a class object (see above). A class
797 instance has a namespace implemented as a dictionary which is the first place in
798 which attribute references are searched. When an attribute is not found there,
799 and the instance's class has an attribute by that name, the search continues
800 with the class attributes. If a class attribute is found that is a user-defined
801 function object or an unbound user-defined method object whose associated class
802 is the class (call it :class:`C`) of the instance for which the attribute
803 reference was initiated or one of its bases, it is transformed into a bound
804 user-defined method object whose :attr:`im_class` attribute is :class:`C` and
805 whose :attr:`im_self` attribute is the instance. Static method and class method
806 objects are also transformed, as if they had been retrieved from class
807 :class:`C`; see above under "Classes". See section :ref:`descriptors` for
808 another way in which attributes of a class retrieved via its instances may
809 differ from the objects actually stored in the class's :attr:`__dict__`. If no
810 class attribute is found, and the object's class has a :meth:`__getattr__`
811 method, that is called to satisfy the lookup.
812
813 .. index:: triple: class instance; attribute; assignment
814
815 Attribute assignments and deletions update the instance's dictionary, never a
816 class's dictionary. If the class has a :meth:`__setattr__` or
817 :meth:`__delattr__` method, this is called instead of updating the instance
818 dictionary directly.
819
820 .. index::
821 object: numeric
822 object: sequence
823 object: mapping
824
825 Class instances can pretend to be numbers, sequences, or mappings if they have
826 methods with certain special names. See section :ref:`specialnames`.
827
828 .. index::
829 single: __dict__ (instance attribute)
830 single: __class__ (instance attribute)
831
832 Special attributes: :attr:`__dict__` is the attribute dictionary;
833 :attr:`__class__` is the instance's class.
834
835Files
836 .. index::
837 object: file
838 builtin: open
839 single: popen() (in module os)
840 single: makefile() (socket method)
841 single: sys.stdin
842 single: sys.stdout
843 single: sys.stderr
844 single: stdio
845 single: stdin (in module sys)
846 single: stdout (in module sys)
847 single: stderr (in module sys)
848
849 A file object represents an open file. File objects are created by the
850 :func:`open` built-in function, and also by :func:`os.popen`,
851 :func:`os.fdopen`, and the :meth:`makefile` method of socket objects (and
852 perhaps by other functions or methods provided by extension modules). The
853 objects ``sys.stdin``, ``sys.stdout`` and ``sys.stderr`` are initialized to
854 file objects corresponding to the interpreter's standard input, output and
855 error streams. See :ref:`bltin-file-objects` for complete documentation of
856 file objects.
857
858Internal types
859 .. index::
860 single: internal type
861 single: types, internal
862
863 A few types used internally by the interpreter are exposed to the user. Their
864 definitions may change with future versions of the interpreter, but they are
865 mentioned here for completeness.
866
867 Code objects
868 .. index::
869 single: bytecode
870 object: code
871
Georg Brandl63fa1682007-10-21 10:24:20 +0000872 Code objects represent *byte-compiled* executable Python code, or :term:`bytecode`.
Georg Brandl8ec7f652007-08-15 14:28:01 +0000873 The difference between a code object and a function object is that the function
874 object contains an explicit reference to the function's globals (the module in
875 which it was defined), while a code object contains no context; also the default
876 argument values are stored in the function object, not in the code object
877 (because they represent values calculated at run-time). Unlike function
878 objects, code objects are immutable and contain no references (directly or
879 indirectly) to mutable objects.
880
881 Special read-only attributes: :attr:`co_name` gives the function name;
882 :attr:`co_argcount` is the number of positional arguments (including arguments
883 with default values); :attr:`co_nlocals` is the number of local variables used
884 by the function (including arguments); :attr:`co_varnames` is a tuple containing
885 the names of the local variables (starting with the argument names);
886 :attr:`co_cellvars` is a tuple containing the names of local variables that are
887 referenced by nested functions; :attr:`co_freevars` is a tuple containing the
888 names of free variables; :attr:`co_code` is a string representing the sequence
889 of bytecode instructions; :attr:`co_consts` is a tuple containing the literals
890 used by the bytecode; :attr:`co_names` is a tuple containing the names used by
891 the bytecode; :attr:`co_filename` is the filename from which the code was
892 compiled; :attr:`co_firstlineno` is the first line number of the function;
Georg Brandl63fa1682007-10-21 10:24:20 +0000893 :attr:`co_lnotab` is a string encoding the mapping from bytecode offsets to
Georg Brandl8ec7f652007-08-15 14:28:01 +0000894 line numbers (for details see the source code of the interpreter);
895 :attr:`co_stacksize` is the required stack size (including local variables);
896 :attr:`co_flags` is an integer encoding a number of flags for the interpreter.
897
898 .. index::
899 single: co_argcount (code object attribute)
900 single: co_code (code object attribute)
901 single: co_consts (code object attribute)
902 single: co_filename (code object attribute)
903 single: co_firstlineno (code object attribute)
904 single: co_flags (code object attribute)
905 single: co_lnotab (code object attribute)
906 single: co_name (code object attribute)
907 single: co_names (code object attribute)
908 single: co_nlocals (code object attribute)
909 single: co_stacksize (code object attribute)
910 single: co_varnames (code object attribute)
911 single: co_cellvars (code object attribute)
912 single: co_freevars (code object attribute)
913
914 .. index:: object: generator
915
916 The following flag bits are defined for :attr:`co_flags`: bit ``0x04`` is set if
917 the function uses the ``*arguments`` syntax to accept an arbitrary number of
918 positional arguments; bit ``0x08`` is set if the function uses the
919 ``**keywords`` syntax to accept arbitrary keyword arguments; bit ``0x20`` is set
920 if the function is a generator.
921
922 Future feature declarations (``from __future__ import division``) also use bits
923 in :attr:`co_flags` to indicate whether a code object was compiled with a
924 particular feature enabled: bit ``0x2000`` is set if the function was compiled
925 with future division enabled; bits ``0x10`` and ``0x1000`` were used in earlier
926 versions of Python.
927
928 Other bits in :attr:`co_flags` are reserved for internal use.
929
930 .. index:: single: documentation string
931
932 If a code object represents a function, the first item in :attr:`co_consts` is
933 the documentation string of the function, or ``None`` if undefined.
934
935 Frame objects
936 .. index:: object: frame
937
938 Frame objects represent execution frames. They may occur in traceback objects
939 (see below).
940
941 .. index::
942 single: f_back (frame attribute)
943 single: f_code (frame attribute)
944 single: f_globals (frame attribute)
945 single: f_locals (frame attribute)
946 single: f_lasti (frame attribute)
947 single: f_builtins (frame attribute)
948 single: f_restricted (frame attribute)
949
950 Special read-only attributes: :attr:`f_back` is to the previous stack frame
951 (towards the caller), or ``None`` if this is the bottom stack frame;
952 :attr:`f_code` is the code object being executed in this frame; :attr:`f_locals`
953 is the dictionary used to look up local variables; :attr:`f_globals` is used for
954 global variables; :attr:`f_builtins` is used for built-in (intrinsic) names;
955 :attr:`f_restricted` is a flag indicating whether the function is executing in
956 restricted execution mode; :attr:`f_lasti` gives the precise instruction (this
957 is an index into the bytecode string of the code object).
958
959 .. index::
960 single: f_trace (frame attribute)
961 single: f_exc_type (frame attribute)
962 single: f_exc_value (frame attribute)
963 single: f_exc_traceback (frame attribute)
964 single: f_lineno (frame attribute)
965
966 Special writable attributes: :attr:`f_trace`, if not ``None``, is a function
967 called at the start of each source code line (this is used by the debugger);
968 :attr:`f_exc_type`, :attr:`f_exc_value`, :attr:`f_exc_traceback` represent the
969 last exception raised in the parent frame provided another exception was ever
970 raised in the current frame (in all other cases they are None); :attr:`f_lineno`
971 is the current line number of the frame --- writing to this from within a trace
972 function jumps to the given line (only for the bottom-most frame). A debugger
973 can implement a Jump command (aka Set Next Statement) by writing to f_lineno.
974
975 Traceback objects
976 .. index::
977 object: traceback
978 pair: stack; trace
979 pair: exception; handler
980 pair: execution; stack
981 single: exc_info (in module sys)
982 single: exc_traceback (in module sys)
983 single: last_traceback (in module sys)
984 single: sys.exc_info
985 single: sys.exc_traceback
986 single: sys.last_traceback
987
988 Traceback objects represent a stack trace of an exception. A traceback object
989 is created when an exception occurs. When the search for an exception handler
990 unwinds the execution stack, at each unwound level a traceback object is
991 inserted in front of the current traceback. When an exception handler is
992 entered, the stack trace is made available to the program. (See section
993 :ref:`try`.) It is accessible as ``sys.exc_traceback``,
994 and also as the third item of the tuple returned by ``sys.exc_info()``. The
995 latter is the preferred interface, since it works correctly when the program is
996 using multiple threads. When the program contains no suitable handler, the stack
997 trace is written (nicely formatted) to the standard error stream; if the
998 interpreter is interactive, it is also made available to the user as
999 ``sys.last_traceback``.
1000
1001 .. index::
1002 single: tb_next (traceback attribute)
1003 single: tb_frame (traceback attribute)
1004 single: tb_lineno (traceback attribute)
1005 single: tb_lasti (traceback attribute)
1006 statement: try
1007
1008 Special read-only attributes: :attr:`tb_next` is the next level in the stack
1009 trace (towards the frame where the exception occurred), or ``None`` if there is
1010 no next level; :attr:`tb_frame` points to the execution frame of the current
1011 level; :attr:`tb_lineno` gives the line number where the exception occurred;
1012 :attr:`tb_lasti` indicates the precise instruction. The line number and last
1013 instruction in the traceback may differ from the line number of its frame object
1014 if the exception occurred in a :keyword:`try` statement with no matching except
1015 clause or with a finally clause.
1016
1017 Slice objects
1018 .. index:: builtin: slice
1019
1020 Slice objects are used to represent slices when *extended slice syntax* is used.
1021 This is a slice using two colons, or multiple slices or ellipses separated by
1022 commas, e.g., ``a[i:j:step]``, ``a[i:j, k:l]``, or ``a[..., i:j]``. They are
1023 also created by the built-in :func:`slice` function.
1024
1025 .. index::
1026 single: start (slice object attribute)
1027 single: stop (slice object attribute)
1028 single: step (slice object attribute)
1029
1030 Special read-only attributes: :attr:`start` is the lower bound; :attr:`stop` is
1031 the upper bound; :attr:`step` is the step value; each is ``None`` if omitted.
1032 These attributes can have any type.
1033
1034 Slice objects support one method:
1035
1036
1037 .. method:: slice.indices(self, length)
1038
1039 This method takes a single integer argument *length* and computes information
1040 about the extended slice that the slice object would describe if applied to a
1041 sequence of *length* items. It returns a tuple of three integers; respectively
1042 these are the *start* and *stop* indices and the *step* or stride length of the
1043 slice. Missing or out-of-bounds indices are handled in a manner consistent with
1044 regular slices.
1045
1046 .. versionadded:: 2.3
1047
1048 Static method objects
1049 Static method objects provide a way of defeating the transformation of function
1050 objects to method objects described above. A static method object is a wrapper
1051 around any other object, usually a user-defined method object. When a static
1052 method object is retrieved from a class or a class instance, the object actually
1053 returned is the wrapped object, which is not subject to any further
1054 transformation. Static method objects are not themselves callable, although the
1055 objects they wrap usually are. Static method objects are created by the built-in
1056 :func:`staticmethod` constructor.
1057
1058 Class method objects
1059 A class method object, like a static method object, is a wrapper around another
1060 object that alters the way in which that object is retrieved from classes and
1061 class instances. The behaviour of class method objects upon such retrieval is
1062 described above, under "User-defined methods". Class method objects are created
1063 by the built-in :func:`classmethod` constructor.
1064
Georg Brandl8ec7f652007-08-15 14:28:01 +00001065
Georg Brandla7395032007-10-21 12:15:05 +00001066.. _newstyle:
Georg Brandl8ec7f652007-08-15 14:28:01 +00001067
1068New-style and classic classes
1069=============================
1070
1071Classes and instances come in two flavors: old-style or classic, and new-style.
1072
1073Up to Python 2.1, old-style classes were the only flavour available to the user.
1074The concept of (old-style) class is unrelated to the concept of type: if *x* is
1075an instance of an old-style class, then ``x.__class__`` designates the class of
1076*x*, but ``type(x)`` is always ``<type 'instance'>``. This reflects the fact
1077that all old-style instances, independently of their class, are implemented with
1078a single built-in type, called ``instance``.
1079
1080New-style classes were introduced in Python 2.2 to unify classes and types. A
1081new-style class neither more nor less than a user-defined type. If *x* is an
1082instance of a new-style class, then ``type(x)`` is the same as ``x.__class__``.
1083
1084The major motivation for introducing new-style classes is to provide a unified
1085object model with a full meta-model. It also has a number of immediate
1086benefits, like the ability to subclass most built-in types, or the introduction
1087of "descriptors", which enable computed properties.
1088
1089For compatibility reasons, classes are still old-style by default. New-style
1090classes are created by specifying another new-style class (i.e. a type) as a
1091parent class, or the "top-level type" :class:`object` if no other parent is
1092needed. The behaviour of new-style classes differs from that of old-style
1093classes in a number of important details in addition to what :func:`type`
1094returns. Some of these changes are fundamental to the new object model, like
1095the way special methods are invoked. Others are "fixes" that could not be
1096implemented before for compatibility concerns, like the method resolution order
1097in case of multiple inheritance.
1098
1099This manual is not up-to-date with respect to new-style classes. For now,
Georg Brandl62658332008-01-05 19:29:45 +00001100please see http://www.python.org/doc/newstyle/ for more information.
Georg Brandl8ec7f652007-08-15 14:28:01 +00001101
1102.. index::
Georg Brandl62658332008-01-05 19:29:45 +00001103 single: class; new-style
1104 single: class; classic
1105 single: class; old-style
Georg Brandl8ec7f652007-08-15 14:28:01 +00001106
1107The plan is to eventually drop old-style classes, leaving only the semantics of
1108new-style classes. This change will probably only be feasible in Python 3.0.
Georg Brandl8ec7f652007-08-15 14:28:01 +00001109
Georg Brandl8ec7f652007-08-15 14:28:01 +00001110
1111.. _specialnames:
1112
1113Special method names
1114====================
1115
1116.. index::
1117 pair: operator; overloading
1118 single: __getitem__() (mapping object method)
1119
1120A class can implement certain operations that are invoked by special syntax
1121(such as arithmetic operations or subscripting and slicing) by defining methods
1122with special names. This is Python's approach to :dfn:`operator overloading`,
1123allowing classes to define their own behavior with respect to language
1124operators. For instance, if a class defines a method named :meth:`__getitem__`,
1125and ``x`` is an instance of this class, then ``x[i]`` is equivalent [#]_ to
1126``x.__getitem__(i)``. Except where mentioned, attempts to execute an operation
1127raise an exception when no appropriate method is defined.
1128
Georg Brandl5768d572007-09-05 13:36:44 +00001129For new-style classes, special methods are only guaranteed to work if defined in
1130an object's class, not in the object's instance dictionary. That explains why
1131this won't work::
1132
1133 >>> class C:
1134 ... pass
1135 ...
1136 >>> c = C()
1137 >>> c.__len__ = lambda: 5
1138 >>> len(c)
1139 Traceback (most recent call last):
1140 File "<stdin>", line 1, in <module>
1141 TypeError: object of type 'C' has no len()
1142
1143
Georg Brandl8ec7f652007-08-15 14:28:01 +00001144When implementing a class that emulates any built-in type, it is important that
1145the emulation only be implemented to the degree that it makes sense for the
1146object being modelled. For example, some sequences may work well with retrieval
1147of individual elements, but extracting a slice may not make sense. (One example
1148of this is the :class:`NodeList` interface in the W3C's Document Object Model.)
1149
1150
1151.. _customization:
1152
1153Basic customization
1154-------------------
1155
1156
1157.. method:: object.__new__(cls[, ...])
1158
1159 Called to create a new instance of class *cls*. :meth:`__new__` is a static
1160 method (special-cased so you need not declare it as such) that takes the class
1161 of which an instance was requested as its first argument. The remaining
1162 arguments are those passed to the object constructor expression (the call to the
1163 class). The return value of :meth:`__new__` should be the new object instance
1164 (usually an instance of *cls*).
1165
1166 Typical implementations create a new instance of the class by invoking the
1167 superclass's :meth:`__new__` method using ``super(currentclass,
1168 cls).__new__(cls[, ...])`` with appropriate arguments and then modifying the
1169 newly-created instance as necessary before returning it.
1170
1171 If :meth:`__new__` returns an instance of *cls*, then the new instance's
1172 :meth:`__init__` method will be invoked like ``__init__(self[, ...])``, where
1173 *self* is the new instance and the remaining arguments are the same as were
1174 passed to :meth:`__new__`.
1175
1176 If :meth:`__new__` does not return an instance of *cls*, then the new instance's
1177 :meth:`__init__` method will not be invoked.
1178
1179 :meth:`__new__` is intended mainly to allow subclasses of immutable types (like
1180 int, str, or tuple) to customize instance creation.
1181
1182
1183.. method:: object.__init__(self[, ...])
1184
1185 .. index:: pair: class; constructor
1186
1187 Called when the instance is created. The arguments are those passed to the
1188 class constructor expression. If a base class has an :meth:`__init__` method,
1189 the derived class's :meth:`__init__` method, if any, must explicitly call it to
1190 ensure proper initialization of the base class part of the instance; for
1191 example: ``BaseClass.__init__(self, [args...])``. As a special constraint on
1192 constructors, no value may be returned; doing so will cause a :exc:`TypeError`
1193 to be raised at runtime.
1194
1195
1196.. method:: object.__del__(self)
1197
1198 .. index::
1199 single: destructor
1200 statement: del
1201
1202 Called when the instance is about to be destroyed. This is also called a
1203 destructor. If a base class has a :meth:`__del__` method, the derived class's
1204 :meth:`__del__` method, if any, must explicitly call it to ensure proper
1205 deletion of the base class part of the instance. Note that it is possible
1206 (though not recommended!) for the :meth:`__del__` method to postpone destruction
1207 of the instance by creating a new reference to it. It may then be called at a
1208 later time when this new reference is deleted. It is not guaranteed that
1209 :meth:`__del__` methods are called for objects that still exist when the
1210 interpreter exits.
1211
1212 .. note::
1213
1214 ``del x`` doesn't directly call ``x.__del__()`` --- the former decrements
1215 the reference count for ``x`` by one, and the latter is only called when
1216 ``x``'s reference count reaches zero. Some common situations that may
1217 prevent the reference count of an object from going to zero include:
1218 circular references between objects (e.g., a doubly-linked list or a tree
1219 data structure with parent and child pointers); a reference to the object
1220 on the stack frame of a function that caught an exception (the traceback
1221 stored in ``sys.exc_traceback`` keeps the stack frame alive); or a
1222 reference to the object on the stack frame that raised an unhandled
1223 exception in interactive mode (the traceback stored in
1224 ``sys.last_traceback`` keeps the stack frame alive). The first situation
1225 can only be remedied by explicitly breaking the cycles; the latter two
1226 situations can be resolved by storing ``None`` in ``sys.exc_traceback`` or
1227 ``sys.last_traceback``. Circular references which are garbage are
1228 detected when the option cycle detector is enabled (it's on by default),
1229 but can only be cleaned up if there are no Python-level :meth:`__del__`
1230 methods involved. Refer to the documentation for the :mod:`gc` module for
1231 more information about how :meth:`__del__` methods are handled by the
1232 cycle detector, particularly the description of the ``garbage`` value.
1233
1234 .. warning::
1235
1236 Due to the precarious circumstances under which :meth:`__del__` methods are
1237 invoked, exceptions that occur during their execution are ignored, and a warning
1238 is printed to ``sys.stderr`` instead. Also, when :meth:`__del__` is invoked in
1239 response to a module being deleted (e.g., when execution of the program is
1240 done), other globals referenced by the :meth:`__del__` method may already have
1241 been deleted. For this reason, :meth:`__del__` methods should do the absolute
1242 minimum needed to maintain external invariants. Starting with version 1.5,
1243 Python guarantees that globals whose name begins with a single underscore are
1244 deleted from their module before other globals are deleted; if no other
1245 references to such globals exist, this may help in assuring that imported
1246 modules are still available at the time when the :meth:`__del__` method is
1247 called.
1248
1249
1250.. method:: object.__repr__(self)
1251
1252 .. index:: builtin: repr
1253
1254 Called by the :func:`repr` built-in function and by string conversions (reverse
1255 quotes) to compute the "official" string representation of an object. If at all
1256 possible, this should look like a valid Python expression that could be used to
1257 recreate an object with the same value (given an appropriate environment). If
1258 this is not possible, a string of the form ``<...some useful description...>``
1259 should be returned. The return value must be a string object. If a class
1260 defines :meth:`__repr__` but not :meth:`__str__`, then :meth:`__repr__` is also
1261 used when an "informal" string representation of instances of that class is
1262 required.
1263
1264 .. index::
1265 pair: string; conversion
1266 pair: reverse; quotes
1267 pair: backward; quotes
1268 single: back-quotes
1269
1270 This is typically used for debugging, so it is important that the representation
1271 is information-rich and unambiguous.
1272
1273
1274.. method:: object.__str__(self)
1275
1276 .. index::
1277 builtin: str
1278 statement: print
1279
1280 Called by the :func:`str` built-in function and by the :keyword:`print`
1281 statement to compute the "informal" string representation of an object. This
1282 differs from :meth:`__repr__` in that it does not have to be a valid Python
1283 expression: a more convenient or concise representation may be used instead.
1284 The return value must be a string object.
1285
1286
1287.. method:: object.__lt__(self, other)
1288 object.__le__(self, other)
1289 object.__eq__(self, other)
1290 object.__ne__(self, other)
1291 object.__gt__(self, other)
1292 object.__ge__(self, other)
1293
1294 .. versionadded:: 2.1
1295
Georg Brandl7c3e79f2007-11-02 20:06:17 +00001296 .. index::
1297 single: comparisons
1298
Georg Brandl8ec7f652007-08-15 14:28:01 +00001299 These are the so-called "rich comparison" methods, and are called for comparison
1300 operators in preference to :meth:`__cmp__` below. The correspondence between
1301 operator symbols and method names is as follows: ``x<y`` calls ``x.__lt__(y)``,
1302 ``x<=y`` calls ``x.__le__(y)``, ``x==y`` calls ``x.__eq__(y)``, ``x!=y`` and
1303 ``x<>y`` call ``x.__ne__(y)``, ``x>y`` calls ``x.__gt__(y)``, and ``x>=y`` calls
1304 ``x.__ge__(y)``.
1305
1306 A rich comparison method may return the singleton ``NotImplemented`` if it does
1307 not implement the operation for a given pair of arguments. By convention,
1308 ``False`` and ``True`` are returned for a successful comparison. However, these
1309 methods can return any value, so if the comparison operator is used in a Boolean
1310 context (e.g., in the condition of an ``if`` statement), Python will call
1311 :func:`bool` on the value to determine if the result is true or false.
1312
Georg Brandl7c3e79f2007-11-02 20:06:17 +00001313 There are no implied relationships among the comparison operators. The truth
1314 of ``x==y`` does not imply that ``x!=y`` is false. Accordingly, when
1315 defining :meth:`__eq__`, one should also define :meth:`__ne__` so that the
1316 operators will behave as expected. See the paragraph on :meth:`__hash__` for
1317 some important notes on creating :term:`hashable` objects which support
1318 custom comparison operations and are usable as dictionary keys.
Georg Brandl8ec7f652007-08-15 14:28:01 +00001319
Georg Brandl7c3e79f2007-11-02 20:06:17 +00001320 There are no swapped-argument versions of these methods (to be used when the
1321 left argument does not support the operation but the right argument does);
1322 rather, :meth:`__lt__` and :meth:`__gt__` are each other's reflection,
Georg Brandl8ec7f652007-08-15 14:28:01 +00001323 :meth:`__le__` and :meth:`__ge__` are each other's reflection, and
1324 :meth:`__eq__` and :meth:`__ne__` are their own reflection.
1325
1326 Arguments to rich comparison methods are never coerced.
1327
1328
1329.. method:: object.__cmp__(self, other)
1330
1331 .. index::
1332 builtin: cmp
1333 single: comparisons
1334
Georg Brandl7c3e79f2007-11-02 20:06:17 +00001335 Called by comparison operations if rich comparison (see above) is not
1336 defined. Should return a negative integer if ``self < other``, zero if
1337 ``self == other``, a positive integer if ``self > other``. If no
1338 :meth:`__cmp__`, :meth:`__eq__` or :meth:`__ne__` operation is defined, class
1339 instances are compared by object identity ("address"). See also the
1340 description of :meth:`__hash__` for some important notes on creating
1341 :term:`hashable` objects which support custom comparison operations and are
1342 usable as dictionary keys. (Note: the restriction that exceptions are not
1343 propagated by :meth:`__cmp__` has been removed since Python 1.5.)
Georg Brandl8ec7f652007-08-15 14:28:01 +00001344
1345
1346.. method:: object.__rcmp__(self, other)
1347
1348 .. versionchanged:: 2.1
1349 No longer supported.
1350
1351
1352.. method:: object.__hash__(self)
1353
1354 .. index::
1355 object: dictionary
1356 builtin: hash
1357
Georg Brandl7c3e79f2007-11-02 20:06:17 +00001358 Called for the key object for dictionary operations, and by the built-in
1359 function :func:`hash`. Should return an integer usable as a hash value
Georg Brandl8ec7f652007-08-15 14:28:01 +00001360 for dictionary operations. The only required property is that objects which
1361 compare equal have the same hash value; it is advised to somehow mix together
1362 (e.g., using exclusive or) the hash values for the components of the object that
Georg Brandl7c3e79f2007-11-02 20:06:17 +00001363 also play a part in comparison of objects.
1364
1365 If a class does not define a :meth:`__cmp__` or :meth:`__eq__` method it
1366 should not define a :meth:`__hash__` operation either; if it defines
1367 :meth:`__cmp__` or :meth:`__eq__` but not :meth:`__hash__`, its instances
1368 will not be usable as dictionary keys. If a class defines mutable objects
1369 and implements a :meth:`__cmp__` or :meth:`__eq__` method, it should not
1370 implement :meth:`__hash__`, since the dictionary implementation requires that
1371 a key's hash value is immutable (if the object's hash value changes, it will
1372 be in the wrong hash bucket).
1373
1374 User-defined classes have :meth:`__cmp__` and :meth:`__hash__` methods
1375 by default; with them, all objects compare unequal and ``x.__hash__()``
1376 returns ``id(x)``.
Georg Brandl8ec7f652007-08-15 14:28:01 +00001377
1378 .. versionchanged:: 2.5
Georg Brandl7c3e79f2007-11-02 20:06:17 +00001379 :meth:`__hash__` may now also return a long integer object; the 32-bit
1380 integer is then derived from the hash of that object.
Georg Brandl8ec7f652007-08-15 14:28:01 +00001381
1382
1383.. method:: object.__nonzero__(self)
1384
1385 .. index:: single: __len__() (mapping object method)
1386
1387 Called to implement truth value testing, and the built-in operation ``bool()``;
1388 should return ``False`` or ``True``, or their integer equivalents ``0`` or
1389 ``1``. When this method is not defined, :meth:`__len__` is called, if it is
1390 defined (see below). If a class defines neither :meth:`__len__` nor
1391 :meth:`__nonzero__`, all its instances are considered true.
1392
1393
1394.. method:: object.__unicode__(self)
1395
1396 .. index:: builtin: unicode
1397
1398 Called to implement :func:`unicode` builtin; should return a Unicode object.
1399 When this method is not defined, string conversion is attempted, and the result
1400 of string conversion is converted to Unicode using the system default encoding.
1401
1402
1403.. _attribute-access:
1404
1405Customizing attribute access
1406----------------------------
1407
1408The following methods can be defined to customize the meaning of attribute
1409access (use of, assignment to, or deletion of ``x.name``) for class instances.
1410
1411
1412.. method:: object.__getattr__(self, name)
1413
1414 Called when an attribute lookup has not found the attribute in the usual places
1415 (i.e. it is not an instance attribute nor is it found in the class tree for
1416 ``self``). ``name`` is the attribute name. This method should return the
1417 (computed) attribute value or raise an :exc:`AttributeError` exception.
1418
1419 .. index:: single: __setattr__() (object method)
1420
1421 Note that if the attribute is found through the normal mechanism,
1422 :meth:`__getattr__` is not called. (This is an intentional asymmetry between
1423 :meth:`__getattr__` and :meth:`__setattr__`.) This is done both for efficiency
1424 reasons and because otherwise :meth:`__setattr__` would have no way to access
1425 other attributes of the instance. Note that at least for instance variables,
1426 you can fake total control by not inserting any values in the instance attribute
1427 dictionary (but instead inserting them in another object). See the
1428 :meth:`__getattribute__` method below for a way to actually get total control in
1429 new-style classes.
1430
1431
1432.. method:: object.__setattr__(self, name, value)
1433
1434 Called when an attribute assignment is attempted. This is called instead of the
1435 normal mechanism (i.e. store the value in the instance dictionary). *name* is
1436 the attribute name, *value* is the value to be assigned to it.
1437
1438 .. index:: single: __dict__ (instance attribute)
1439
1440 If :meth:`__setattr__` wants to assign to an instance attribute, it should not
1441 simply execute ``self.name = value`` --- this would cause a recursive call to
1442 itself. Instead, it should insert the value in the dictionary of instance
1443 attributes, e.g., ``self.__dict__[name] = value``. For new-style classes,
1444 rather than accessing the instance dictionary, it should call the base class
1445 method with the same name, for example, ``object.__setattr__(self, name,
1446 value)``.
1447
1448
1449.. method:: object.__delattr__(self, name)
1450
1451 Like :meth:`__setattr__` but for attribute deletion instead of assignment. This
1452 should only be implemented if ``del obj.name`` is meaningful for the object.
1453
1454
1455.. _new-style-attribute-access:
1456
1457More attribute access for new-style classes
1458^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
1459
1460The following methods only apply to new-style classes.
1461
1462
1463.. method:: object.__getattribute__(self, name)
1464
1465 Called unconditionally to implement attribute accesses for instances of the
1466 class. If the class also defines :meth:`__getattr__`, the latter will not be
1467 called unless :meth:`__getattribute__` either calls it explicitly or raises an
1468 :exc:`AttributeError`. This method should return the (computed) attribute value
1469 or raise an :exc:`AttributeError` exception. In order to avoid infinite
1470 recursion in this method, its implementation should always call the base class
1471 method with the same name to access any attributes it needs, for example,
1472 ``object.__getattribute__(self, name)``.
1473
1474
1475.. _descriptors:
1476
1477Implementing Descriptors
1478^^^^^^^^^^^^^^^^^^^^^^^^
1479
1480The following methods only apply when an instance of the class containing the
1481method (a so-called *descriptor* class) appears in the class dictionary of
1482another new-style class, known as the *owner* class. In the examples below, "the
1483attribute" refers to the attribute whose name is the key of the property in the
1484owner class' ``__dict__``. Descriptors can only be implemented as new-style
1485classes themselves.
1486
1487
1488.. method:: object.__get__(self, instance, owner)
1489
1490 Called to get the attribute of the owner class (class attribute access) or of an
1491 instance of that class (instance attribute access). *owner* is always the owner
1492 class, while *instance* is the instance that the attribute was accessed through,
1493 or ``None`` when the attribute is accessed through the *owner*. This method
1494 should return the (computed) attribute value or raise an :exc:`AttributeError`
1495 exception.
1496
1497
1498.. method:: object.__set__(self, instance, value)
1499
1500 Called to set the attribute on an instance *instance* of the owner class to a
1501 new value, *value*.
1502
1503
1504.. method:: object.__delete__(self, instance)
1505
1506 Called to delete the attribute on an instance *instance* of the owner class.
1507
1508
1509.. _descriptor-invocation:
1510
1511Invoking Descriptors
1512^^^^^^^^^^^^^^^^^^^^
1513
1514In general, a descriptor is an object attribute with "binding behavior", one
1515whose attribute access has been overridden by methods in the descriptor
1516protocol: :meth:`__get__`, :meth:`__set__`, and :meth:`__delete__`. If any of
1517those methods are defined for an object, it is said to be a descriptor.
1518
1519The default behavior for attribute access is to get, set, or delete the
1520attribute from an object's dictionary. For instance, ``a.x`` has a lookup chain
1521starting with ``a.__dict__['x']``, then ``type(a).__dict__['x']``, and
1522continuing through the base classes of ``type(a)`` excluding metaclasses.
1523
1524However, if the looked-up value is an object defining one of the descriptor
1525methods, then Python may override the default behavior and invoke the descriptor
1526method instead. Where this occurs in the precedence chain depends on which
1527descriptor methods were defined and how they were called. Note that descriptors
1528are only invoked for new style objects or classes (ones that subclass
1529:class:`object()` or :class:`type()`).
1530
1531The starting point for descriptor invocation is a binding, ``a.x``. How the
1532arguments are assembled depends on ``a``:
1533
1534Direct Call
1535 The simplest and least common call is when user code directly invokes a
1536 descriptor method: ``x.__get__(a)``.
1537
1538Instance Binding
1539 If binding to a new-style object instance, ``a.x`` is transformed into the call:
1540 ``type(a).__dict__['x'].__get__(a, type(a))``.
1541
1542Class Binding
1543 If binding to a new-style class, ``A.x`` is transformed into the call:
1544 ``A.__dict__['x'].__get__(None, A)``.
1545
1546Super Binding
1547 If ``a`` is an instance of :class:`super`, then the binding ``super(B,
1548 obj).m()`` searches ``obj.__class__.__mro__`` for the base class ``A``
1549 immediately preceding ``B`` and then invokes the descriptor with the call:
1550 ``A.__dict__['m'].__get__(obj, A)``.
1551
1552For instance bindings, the precedence of descriptor invocation depends on the
Georg Brandl37614222007-08-23 21:42:54 +00001553which descriptor methods are defined. Normally, data descriptors define both
1554:meth:`__get__` and :meth:`__set__`, while non-data descriptors have just the
Georg Brandl8ec7f652007-08-15 14:28:01 +00001555:meth:`__get__` method. Data descriptors always override a redefinition in an
1556instance dictionary. In contrast, non-data descriptors can be overridden by
Georg Brandl37614222007-08-23 21:42:54 +00001557instances. [#]_
Georg Brandl8ec7f652007-08-15 14:28:01 +00001558
1559Python methods (including :func:`staticmethod` and :func:`classmethod`) are
1560implemented as non-data descriptors. Accordingly, instances can redefine and
1561override methods. This allows individual instances to acquire behaviors that
1562differ from other instances of the same class.
1563
1564The :func:`property` function is implemented as a data descriptor. Accordingly,
1565instances cannot override the behavior of a property.
1566
1567
1568.. _slots:
1569
1570__slots__
1571^^^^^^^^^
1572
1573By default, instances of both old and new-style classes have a dictionary for
1574attribute storage. This wastes space for objects having very few instance
1575variables. The space consumption can become acute when creating large numbers
1576of instances.
1577
1578The default can be overridden by defining *__slots__* in a new-style class
1579definition. The *__slots__* declaration takes a sequence of instance variables
1580and reserves just enough space in each instance to hold a value for each
1581variable. Space is saved because *__dict__* is not created for each instance.
1582
1583
1584.. data:: __slots__
1585
1586 This class variable can be assigned a string, iterable, or sequence of strings
1587 with variable names used by instances. If defined in a new-style class,
1588 *__slots__* reserves space for the declared variables and prevents the automatic
1589 creation of *__dict__* and *__weakref__* for each instance.
1590
1591 .. versionadded:: 2.2
1592
1593Notes on using *__slots__*
1594
1595* Without a *__dict__* variable, instances cannot be assigned new variables not
1596 listed in the *__slots__* definition. Attempts to assign to an unlisted
1597 variable name raises :exc:`AttributeError`. If dynamic assignment of new
1598 variables is desired, then add ``'__dict__'`` to the sequence of strings in the
1599 *__slots__* declaration.
1600
1601 .. versionchanged:: 2.3
1602 Previously, adding ``'__dict__'`` to the *__slots__* declaration would not
1603 enable the assignment of new attributes not specifically listed in the sequence
1604 of instance variable names.
1605
1606* Without a *__weakref__* variable for each instance, classes defining
1607 *__slots__* do not support weak references to its instances. If weak reference
1608 support is needed, then add ``'__weakref__'`` to the sequence of strings in the
1609 *__slots__* declaration.
1610
1611 .. versionchanged:: 2.3
1612 Previously, adding ``'__weakref__'`` to the *__slots__* declaration would not
1613 enable support for weak references.
1614
1615* *__slots__* are implemented at the class level by creating descriptors
1616 (:ref:`descriptors`) for each variable name. As a result, class attributes
1617 cannot be used to set default values for instance variables defined by
1618 *__slots__*; otherwise, the class attribute would overwrite the descriptor
1619 assignment.
1620
1621* If a class defines a slot also defined in a base class, the instance variable
1622 defined by the base class slot is inaccessible (except by retrieving its
1623 descriptor directly from the base class). This renders the meaning of the
1624 program undefined. In the future, a check may be added to prevent this.
1625
1626* The action of a *__slots__* declaration is limited to the class where it is
1627 defined. As a result, subclasses will have a *__dict__* unless they also define
1628 *__slots__*.
1629
1630* *__slots__* do not work for classes derived from "variable-length" built-in
1631 types such as :class:`long`, :class:`str` and :class:`tuple`.
1632
1633* Any non-string iterable may be assigned to *__slots__*. Mappings may also be
1634 used; however, in the future, special meaning may be assigned to the values
1635 corresponding to each key.
1636
1637* *__class__* assignment works only if both classes have the same *__slots__*.
1638
1639 .. versionchanged:: 2.6
1640 Previously, *__class__* assignment raised an error if either new or old class
1641 had *__slots__*.
1642
1643
1644.. _metaclasses:
1645
1646Customizing class creation
1647--------------------------
1648
1649By default, new-style classes are constructed using :func:`type`. A class
1650definition is read into a separate namespace and the value of class name is
1651bound to the result of ``type(name, bases, dict)``.
1652
1653When the class definition is read, if *__metaclass__* is defined then the
1654callable assigned to it will be called instead of :func:`type`. The allows
1655classes or functions to be written which monitor or alter the class creation
1656process:
1657
1658* Modifying the class dictionary prior to the class being created.
1659
1660* Returning an instance of another class -- essentially performing the role of a
1661 factory function.
1662
1663
1664.. data:: __metaclass__
1665
1666 This variable can be any callable accepting arguments for ``name``, ``bases``,
1667 and ``dict``. Upon class creation, the callable is used instead of the built-in
1668 :func:`type`.
1669
1670 .. versionadded:: 2.2
1671
1672The appropriate metaclass is determined by the following precedence rules:
1673
1674* If ``dict['__metaclass__']`` exists, it is used.
1675
1676* Otherwise, if there is at least one base class, its metaclass is used (this
1677 looks for a *__class__* attribute first and if not found, uses its type).
1678
1679* Otherwise, if a global variable named __metaclass__ exists, it is used.
1680
1681* Otherwise, the old-style, classic metaclass (types.ClassType) is used.
1682
1683The potential uses for metaclasses are boundless. Some ideas that have been
1684explored including logging, interface checking, automatic delegation, automatic
1685property creation, proxies, frameworks, and automatic resource
1686locking/synchronization.
1687
1688
1689.. _callable-types:
1690
1691Emulating callable objects
1692--------------------------
1693
1694
1695.. method:: object.__call__(self[, args...])
1696
1697 .. index:: pair: call; instance
1698
1699 Called when the instance is "called" as a function; if this method is defined,
1700 ``x(arg1, arg2, ...)`` is a shorthand for ``x.__call__(arg1, arg2, ...)``.
1701
1702
1703.. _sequence-types:
1704
1705Emulating container types
1706-------------------------
1707
1708The following methods can be defined to implement container objects. Containers
1709usually are sequences (such as lists or tuples) or mappings (like dictionaries),
1710but can represent other containers as well. The first set of methods is used
1711either to emulate a sequence or to emulate a mapping; the difference is that for
1712a sequence, the allowable keys should be the integers *k* for which ``0 <= k <
1713N`` where *N* is the length of the sequence, or slice objects, which define a
1714range of items. (For backwards compatibility, the method :meth:`__getslice__`
1715(see below) can also be defined to handle simple, but not extended slices.) It
1716is also recommended that mappings provide the methods :meth:`keys`,
1717:meth:`values`, :meth:`items`, :meth:`has_key`, :meth:`get`, :meth:`clear`,
1718:meth:`setdefault`, :meth:`iterkeys`, :meth:`itervalues`, :meth:`iteritems`,
1719:meth:`pop`, :meth:`popitem`, :meth:`copy`, and :meth:`update` behaving similar
1720to those for Python's standard dictionary objects. The :mod:`UserDict` module
1721provides a :class:`DictMixin` class to help create those methods from a base set
1722of :meth:`__getitem__`, :meth:`__setitem__`, :meth:`__delitem__`, and
1723:meth:`keys`. Mutable sequences should provide methods :meth:`append`,
1724:meth:`count`, :meth:`index`, :meth:`extend`, :meth:`insert`, :meth:`pop`,
1725:meth:`remove`, :meth:`reverse` and :meth:`sort`, like Python standard list
1726objects. Finally, sequence types should implement addition (meaning
1727concatenation) and multiplication (meaning repetition) by defining the methods
1728:meth:`__add__`, :meth:`__radd__`, :meth:`__iadd__`, :meth:`__mul__`,
1729:meth:`__rmul__` and :meth:`__imul__` described below; they should not define
1730:meth:`__coerce__` or other numerical operators. It is recommended that both
1731mappings and sequences implement the :meth:`__contains__` method to allow
1732efficient use of the ``in`` operator; for mappings, ``in`` should be equivalent
1733of :meth:`has_key`; for sequences, it should search through the values. It is
1734further recommended that both mappings and sequences implement the
1735:meth:`__iter__` method to allow efficient iteration through the container; for
1736mappings, :meth:`__iter__` should be the same as :meth:`iterkeys`; for
1737sequences, it should iterate through the values.
1738
1739
1740.. method:: object.__len__(self)
1741
1742 .. index::
1743 builtin: len
1744 single: __nonzero__() (object method)
1745
1746 Called to implement the built-in function :func:`len`. Should return the length
1747 of the object, an integer ``>=`` 0. Also, an object that doesn't define a
1748 :meth:`__nonzero__` method and whose :meth:`__len__` method returns zero is
1749 considered to be false in a Boolean context.
1750
1751
1752.. method:: object.__getitem__(self, key)
1753
1754 .. index:: object: slice
1755
1756 Called to implement evaluation of ``self[key]``. For sequence types, the
1757 accepted keys should be integers and slice objects. Note that the special
1758 interpretation of negative indexes (if the class wishes to emulate a sequence
1759 type) is up to the :meth:`__getitem__` method. If *key* is of an inappropriate
1760 type, :exc:`TypeError` may be raised; if of a value outside the set of indexes
1761 for the sequence (after any special interpretation of negative values),
1762 :exc:`IndexError` should be raised. For mapping types, if *key* is missing (not
1763 in the container), :exc:`KeyError` should be raised.
1764
1765 .. note::
1766
1767 :keyword:`for` loops expect that an :exc:`IndexError` will be raised for illegal
1768 indexes to allow proper detection of the end of the sequence.
1769
1770
1771.. method:: object.__setitem__(self, key, value)
1772
1773 Called to implement assignment to ``self[key]``. Same note as for
1774 :meth:`__getitem__`. This should only be implemented for mappings if the
1775 objects support changes to the values for keys, or if new keys can be added, or
1776 for sequences if elements can be replaced. The same exceptions should be raised
1777 for improper *key* values as for the :meth:`__getitem__` method.
1778
1779
1780.. method:: object.__delitem__(self, key)
1781
1782 Called to implement deletion of ``self[key]``. Same note as for
1783 :meth:`__getitem__`. This should only be implemented for mappings if the
1784 objects support removal of keys, or for sequences if elements can be removed
1785 from the sequence. The same exceptions should be raised for improper *key*
1786 values as for the :meth:`__getitem__` method.
1787
1788
1789.. method:: object.__iter__(self)
1790
1791 This method is called when an iterator is required for a container. This method
1792 should return a new iterator object that can iterate over all the objects in the
1793 container. For mappings, it should iterate over the keys of the container, and
1794 should also be made available as the method :meth:`iterkeys`.
1795
1796 Iterator objects also need to implement this method; they are required to return
1797 themselves. For more information on iterator objects, see :ref:`typeiter`.
1798
1799The membership test operators (:keyword:`in` and :keyword:`not in`) are normally
1800implemented as an iteration through a sequence. However, container objects can
1801supply the following special method with a more efficient implementation, which
1802also does not require the object be a sequence.
1803
1804
1805.. method:: object.__contains__(self, item)
1806
1807 Called to implement membership test operators. Should return true if *item* is
1808 in *self*, false otherwise. For mapping objects, this should consider the keys
1809 of the mapping rather than the values or the key-item pairs.
1810
1811
1812.. _sequence-methods:
1813
1814Additional methods for emulation of sequence types
1815--------------------------------------------------
1816
1817The following optional methods can be defined to further emulate sequence
1818objects. Immutable sequences methods should at most only define
1819:meth:`__getslice__`; mutable sequences might define all three methods.
1820
1821
1822.. method:: object.__getslice__(self, i, j)
1823
1824 .. deprecated:: 2.0
1825 Support slice objects as parameters to the :meth:`__getitem__` method.
Georg Brandl8d9e8452007-08-23 20:35:00 +00001826 (However, built-in types in CPython currently still implement
1827 :meth:`__getslice__`. Therefore, you have to override it in derived
1828 classes when implementing slicing.)
Georg Brandl8ec7f652007-08-15 14:28:01 +00001829
1830 Called to implement evaluation of ``self[i:j]``. The returned object should be
1831 of the same type as *self*. Note that missing *i* or *j* in the slice
1832 expression are replaced by zero or ``sys.maxint``, respectively. If negative
1833 indexes are used in the slice, the length of the sequence is added to that
1834 index. If the instance does not implement the :meth:`__len__` method, an
1835 :exc:`AttributeError` is raised. No guarantee is made that indexes adjusted this
1836 way are not still negative. Indexes which are greater than the length of the
1837 sequence are not modified. If no :meth:`__getslice__` is found, a slice object
1838 is created instead, and passed to :meth:`__getitem__` instead.
1839
1840
1841.. method:: object.__setslice__(self, i, j, sequence)
1842
1843 Called to implement assignment to ``self[i:j]``. Same notes for *i* and *j* as
1844 for :meth:`__getslice__`.
1845
1846 This method is deprecated. If no :meth:`__setslice__` is found, or for extended
1847 slicing of the form ``self[i:j:k]``, a slice object is created, and passed to
1848 :meth:`__setitem__`, instead of :meth:`__setslice__` being called.
1849
1850
1851.. method:: object.__delslice__(self, i, j)
1852
1853 Called to implement deletion of ``self[i:j]``. Same notes for *i* and *j* as for
1854 :meth:`__getslice__`. This method is deprecated. If no :meth:`__delslice__` is
1855 found, or for extended slicing of the form ``self[i:j:k]``, a slice object is
1856 created, and passed to :meth:`__delitem__`, instead of :meth:`__delslice__`
1857 being called.
1858
1859Notice that these methods are only invoked when a single slice with a single
1860colon is used, and the slice method is available. For slice operations
1861involving extended slice notation, or in absence of the slice methods,
1862:meth:`__getitem__`, :meth:`__setitem__` or :meth:`__delitem__` is called with a
1863slice object as argument.
1864
1865The following example demonstrate how to make your program or module compatible
1866with earlier versions of Python (assuming that methods :meth:`__getitem__`,
1867:meth:`__setitem__` and :meth:`__delitem__` support slice objects as
1868arguments)::
1869
1870 class MyClass:
1871 ...
1872 def __getitem__(self, index):
1873 ...
1874 def __setitem__(self, index, value):
1875 ...
1876 def __delitem__(self, index):
1877 ...
1878
1879 if sys.version_info < (2, 0):
1880 # They won't be defined if version is at least 2.0 final
1881
1882 def __getslice__(self, i, j):
1883 return self[max(0, i):max(0, j):]
1884 def __setslice__(self, i, j, seq):
1885 self[max(0, i):max(0, j):] = seq
1886 def __delslice__(self, i, j):
1887 del self[max(0, i):max(0, j):]
1888 ...
1889
1890Note the calls to :func:`max`; these are necessary because of the handling of
1891negative indices before the :meth:`__\*slice__` methods are called. When
1892negative indexes are used, the :meth:`__\*item__` methods receive them as
1893provided, but the :meth:`__\*slice__` methods get a "cooked" form of the index
1894values. For each negative index value, the length of the sequence is added to
1895the index before calling the method (which may still result in a negative
1896index); this is the customary handling of negative indexes by the built-in
1897sequence types, and the :meth:`__\*item__` methods are expected to do this as
1898well. However, since they should already be doing that, negative indexes cannot
1899be passed in; they must be constrained to the bounds of the sequence before
1900being passed to the :meth:`__\*item__` methods. Calling ``max(0, i)``
1901conveniently returns the proper value.
1902
1903
1904.. _numeric-types:
1905
1906Emulating numeric types
1907-----------------------
1908
1909The following methods can be defined to emulate numeric objects. Methods
1910corresponding to operations that are not supported by the particular kind of
1911number implemented (e.g., bitwise operations for non-integral numbers) should be
1912left undefined.
1913
1914
1915.. method:: object.__add__(self, other)
1916 object.__sub__(self, other)
1917 object.__mul__(self, other)
1918 object.__floordiv__(self, other)
1919 object.__mod__(self, other)
1920 object.__divmod__(self, other)
1921 object.__pow__(self, other[, modulo])
1922 object.__lshift__(self, other)
1923 object.__rshift__(self, other)
1924 object.__and__(self, other)
1925 object.__xor__(self, other)
1926 object.__or__(self, other)
1927
1928 .. index::
1929 builtin: divmod
1930 builtin: pow
1931 builtin: pow
1932
1933 These methods are called to implement the binary arithmetic operations (``+``,
1934 ``-``, ``*``, ``//``, ``%``, :func:`divmod`, :func:`pow`, ``**``, ``<<``,
1935 ``>>``, ``&``, ``^``, ``|``). For instance, to evaluate the expression
1936 *x*``+``*y*, where *x* is an instance of a class that has an :meth:`__add__`
1937 method, ``x.__add__(y)`` is called. The :meth:`__divmod__` method should be the
1938 equivalent to using :meth:`__floordiv__` and :meth:`__mod__`; it should not be
1939 related to :meth:`__truediv__` (described below). Note that :meth:`__pow__`
1940 should be defined to accept an optional third argument if the ternary version of
1941 the built-in :func:`pow` function is to be supported.
1942
1943 If one of those methods does not support the operation with the supplied
1944 arguments, it should return ``NotImplemented``.
1945
1946
1947.. method:: object.__div__(self, other)
1948 object.__truediv__(self, other)
1949
1950 The division operator (``/``) is implemented by these methods. The
1951 :meth:`__truediv__` method is used when ``__future__.division`` is in effect,
1952 otherwise :meth:`__div__` is used. If only one of these two methods is defined,
1953 the object will not support division in the alternate context; :exc:`TypeError`
1954 will be raised instead.
1955
1956
1957.. method:: object.__radd__(self, other)
1958 object.__rsub__(self, other)
1959 object.__rmul__(self, other)
1960 object.__rdiv__(self, other)
1961 object.__rtruediv__(self, other)
1962 object.__rfloordiv__(self, other)
1963 object.__rmod__(self, other)
1964 object.__rdivmod__(self, other)
1965 object.__rpow__(self, other)
1966 object.__rlshift__(self, other)
1967 object.__rrshift__(self, other)
1968 object.__rand__(self, other)
1969 object.__rxor__(self, other)
1970 object.__ror__(self, other)
1971
1972 .. index::
1973 builtin: divmod
1974 builtin: pow
1975
1976 These methods are called to implement the binary arithmetic operations (``+``,
1977 ``-``, ``*``, ``/``, ``%``, :func:`divmod`, :func:`pow`, ``**``, ``<<``, ``>>``,
1978 ``&``, ``^``, ``|``) with reflected (swapped) operands. These functions are
1979 only called if the left operand does not support the corresponding operation and
1980 the operands are of different types. [#]_ For instance, to evaluate the
1981 expression *x*``-``*y*, where *y* is an instance of a class that has an
1982 :meth:`__rsub__` method, ``y.__rsub__(x)`` is called if ``x.__sub__(y)`` returns
1983 *NotImplemented*.
1984
1985 .. index:: builtin: pow
1986
1987 Note that ternary :func:`pow` will not try calling :meth:`__rpow__` (the
1988 coercion rules would become too complicated).
1989
1990 .. note::
1991
1992 If the right operand's type is a subclass of the left operand's type and that
1993 subclass provides the reflected method for the operation, this method will be
1994 called before the left operand's non-reflected method. This behavior allows
1995 subclasses to override their ancestors' operations.
1996
1997
1998.. method:: object.__iadd__(self, other)
1999 object.__isub__(self, other)
2000 object.__imul__(self, other)
2001 object.__idiv__(self, other)
2002 object.__itruediv__(self, other)
2003 object.__ifloordiv__(self, other)
2004 object.__imod__(self, other)
2005 object.__ipow__(self, other[, modulo])
2006 object.__ilshift__(self, other)
2007 object.__irshift__(self, other)
2008 object.__iand__(self, other)
2009 object.__ixor__(self, other)
2010 object.__ior__(self, other)
2011
2012 These methods are called to implement the augmented arithmetic operations
2013 (``+=``, ``-=``, ``*=``, ``/=``, ``//=``, ``%=``, ``**=``, ``<<=``, ``>>=``,
2014 ``&=``, ``^=``, ``|=``). These methods should attempt to do the operation
2015 in-place (modifying *self*) and return the result (which could be, but does
2016 not have to be, *self*). If a specific method is not defined, the augmented
2017 operation falls back to the normal methods. For instance, to evaluate the
2018 expression *x*``+=``*y*, where *x* is an instance of a class that has an
2019 :meth:`__iadd__` method, ``x.__iadd__(y)`` is called. If *x* is an instance
2020 of a class that does not define a :meth:`__iadd__` method, ``x.__add__(y)``
2021 and ``y.__radd__(x)`` are considered, as with the evaluation of *x*``+``*y*.
2022
2023
2024.. method:: object.__neg__(self)
2025 object.__pos__(self)
2026 object.__abs__(self)
2027 object.__invert__(self)
2028
2029 .. index:: builtin: abs
2030
2031 Called to implement the unary arithmetic operations (``-``, ``+``, :func:`abs`
2032 and ``~``).
2033
2034
2035.. method:: object.__complex__(self)
2036 object.__int__(self)
2037 object.__long__(self)
2038 object.__float__(self)
2039
2040 .. index::
2041 builtin: complex
2042 builtin: int
2043 builtin: long
2044 builtin: float
2045
2046 Called to implement the built-in functions :func:`complex`, :func:`int`,
2047 :func:`long`, and :func:`float`. Should return a value of the appropriate type.
2048
2049
2050.. method:: object.__oct__(self)
2051 object.__hex__(self)
2052
2053 .. index::
2054 builtin: oct
2055 builtin: hex
2056
2057 Called to implement the built-in functions :func:`oct` and :func:`hex`. Should
2058 return a string value.
2059
2060
2061.. method:: object.__index__(self)
2062
2063 Called to implement :func:`operator.index`. Also called whenever Python needs
2064 an integer object (such as in slicing). Must return an integer (int or long).
2065
2066 .. versionadded:: 2.5
2067
2068
2069.. method:: object.__coerce__(self, other)
2070
2071 Called to implement "mixed-mode" numeric arithmetic. Should either return a
2072 2-tuple containing *self* and *other* converted to a common numeric type, or
2073 ``None`` if conversion is impossible. When the common type would be the type of
2074 ``other``, it is sufficient to return ``None``, since the interpreter will also
2075 ask the other object to attempt a coercion (but sometimes, if the implementation
2076 of the other type cannot be changed, it is useful to do the conversion to the
2077 other type here). A return value of ``NotImplemented`` is equivalent to
2078 returning ``None``.
2079
2080
2081.. _coercion-rules:
2082
2083Coercion rules
2084--------------
2085
2086This section used to document the rules for coercion. As the language has
2087evolved, the coercion rules have become hard to document precisely; documenting
2088what one version of one particular implementation does is undesirable. Instead,
2089here are some informal guidelines regarding coercion. In Python 3.0, coercion
2090will not be supported.
2091
2092*
2093
2094 If the left operand of a % operator is a string or Unicode object, no coercion
2095 takes place and the string formatting operation is invoked instead.
2096
2097*
2098
2099 It is no longer recommended to define a coercion operation. Mixed-mode
2100 operations on types that don't define coercion pass the original arguments to
2101 the operation.
2102
2103*
2104
2105 New-style classes (those derived from :class:`object`) never invoke the
2106 :meth:`__coerce__` method in response to a binary operator; the only time
2107 :meth:`__coerce__` is invoked is when the built-in function :func:`coerce` is
2108 called.
2109
2110*
2111
2112 For most intents and purposes, an operator that returns ``NotImplemented`` is
2113 treated the same as one that is not implemented at all.
2114
2115*
2116
2117 Below, :meth:`__op__` and :meth:`__rop__` are used to signify the generic method
2118 names corresponding to an operator; :meth:`__iop__` is used for the
2119 corresponding in-place operator. For example, for the operator '``+``',
2120 :meth:`__add__` and :meth:`__radd__` are used for the left and right variant of
2121 the binary operator, and :meth:`__iadd__` for the in-place variant.
2122
2123*
2124
2125 For objects *x* and *y*, first ``x.__op__(y)`` is tried. If this is not
2126 implemented or returns ``NotImplemented``, ``y.__rop__(x)`` is tried. If this
2127 is also not implemented or returns ``NotImplemented``, a :exc:`TypeError`
2128 exception is raised. But see the following exception:
2129
2130*
2131
2132 Exception to the previous item: if the left operand is an instance of a built-in
2133 type or a new-style class, and the right operand is an instance of a proper
2134 subclass of that type or class and overrides the base's :meth:`__rop__` method,
2135 the right operand's :meth:`__rop__` method is tried *before* the left operand's
2136 :meth:`__op__` method.
2137
2138 This is done so that a subclass can completely override binary operators.
2139 Otherwise, the left operand's :meth:`__op__` method would always accept the
2140 right operand: when an instance of a given class is expected, an instance of a
2141 subclass of that class is always acceptable.
2142
2143*
2144
2145 When either operand type defines a coercion, this coercion is called before that
2146 type's :meth:`__op__` or :meth:`__rop__` method is called, but no sooner. If
2147 the coercion returns an object of a different type for the operand whose
2148 coercion is invoked, part of the process is redone using the new object.
2149
2150*
2151
2152 When an in-place operator (like '``+=``') is used, if the left operand
2153 implements :meth:`__iop__`, it is invoked without any coercion. When the
2154 operation falls back to :meth:`__op__` and/or :meth:`__rop__`, the normal
2155 coercion rules apply.
2156
2157*
2158
2159 In *x*``+``*y*, if *x* is a sequence that implements sequence concatenation,
2160 sequence concatenation is invoked.
2161
2162*
2163
2164 In *x*``*``*y*, if one operator is a sequence that implements sequence
2165 repetition, and the other is an integer (:class:`int` or :class:`long`),
2166 sequence repetition is invoked.
2167
2168*
2169
2170 Rich comparisons (implemented by methods :meth:`__eq__` and so on) never use
2171 coercion. Three-way comparison (implemented by :meth:`__cmp__`) does use
2172 coercion under the same conditions as other binary operations use it.
2173
2174*
2175
2176 In the current implementation, the built-in numeric types :class:`int`,
2177 :class:`long` and :class:`float` do not use coercion; the type :class:`complex`
2178 however does use it. The difference can become apparent when subclassing these
2179 types. Over time, the type :class:`complex` may be fixed to avoid coercion.
2180 All these types implement a :meth:`__coerce__` method, for use by the built-in
2181 :func:`coerce` function.
2182
2183
2184.. _context-managers:
2185
2186With Statement Context Managers
2187-------------------------------
2188
2189.. versionadded:: 2.5
2190
2191A :dfn:`context manager` is an object that defines the runtime context to be
2192established when executing a :keyword:`with` statement. The context manager
2193handles the entry into, and the exit from, the desired runtime context for the
2194execution of the block of code. Context managers are normally invoked using the
2195:keyword:`with` statement (described in section :ref:`with`), but can also be
2196used by directly invoking their methods.
2197
2198.. index::
2199 statement: with
2200 single: context manager
2201
2202Typical uses of context managers include saving and restoring various kinds of
2203global state, locking and unlocking resources, closing opened files, etc.
2204
2205For more information on context managers, see :ref:`typecontextmanager`.
2206
2207
2208.. method:: object.__enter__(self)
2209
2210 Enter the runtime context related to this object. The :keyword:`with` statement
2211 will bind this method's return value to the target(s) specified in the
2212 :keyword:`as` clause of the statement, if any.
2213
2214
2215.. method:: object.__exit__(self, exc_type, exc_value, traceback)
2216
2217 Exit the runtime context related to this object. The parameters describe the
2218 exception that caused the context to be exited. If the context was exited
2219 without an exception, all three arguments will be :const:`None`.
2220
2221 If an exception is supplied, and the method wishes to suppress the exception
2222 (i.e., prevent it from being propagated), it should return a true value.
2223 Otherwise, the exception will be processed normally upon exit from this method.
2224
2225 Note that :meth:`__exit__` methods should not reraise the passed-in exception;
2226 this is the caller's responsibility.
2227
2228
2229.. seealso::
2230
2231 :pep:`0343` - The "with" statement
2232 The specification, background, and examples for the Python :keyword:`with`
2233 statement.
2234
2235.. rubric:: Footnotes
2236
2237.. [#] Since Python 2.2, a gradual merging of types and classes has been started that
2238 makes this and a few other assertions made in this manual not 100% accurate and
2239 complete: for example, it *is* now possible in some cases to change an object's
2240 type, under certain controlled conditions. Until this manual undergoes
2241 extensive revision, it must now be taken as authoritative only regarding
2242 "classic classes", that are still the default, for compatibility purposes, in
2243 Python 2.2 and 2.3. For more information, see
Georg Brandl62658332008-01-05 19:29:45 +00002244 http://www.python.org/doc/newstyle/.
Georg Brandl8ec7f652007-08-15 14:28:01 +00002245
2246.. [#] This, and other statements, are only roughly true for instances of new-style
2247 classes.
2248
Georg Brandl37614222007-08-23 21:42:54 +00002249.. [#] A descriptor can define any combination of :meth:`__get__`,
2250 :meth:`__set__` and :meth:`__delete__`. If it does not define :meth:`__get__`,
2251 then accessing the attribute even on an instance will return the descriptor
2252 object itself. If the descriptor defines :meth:`__set__` and/or
2253 :meth:`__delete__`, it is a data descriptor; if it defines neither, it is a
2254 non-data descriptor.
2255
Georg Brandl8ec7f652007-08-15 14:28:01 +00002256.. [#] For operands of the same type, it is assumed that if the non-reflected method
2257 (such as :meth:`__add__`) fails the operation is not supported, which is why the
2258 reflected method is not called.
2259