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