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