|
1 .. _tut-classes: |
|
2 |
|
3 ******* |
|
4 Classes |
|
5 ******* |
|
6 |
|
7 Python's class mechanism adds classes to the language with a minimum of new |
|
8 syntax and semantics. It is a mixture of the class mechanisms found in C++ and |
|
9 Modula-3. As is true for modules, classes in Python do not put an absolute |
|
10 barrier between definition and user, but rather rely on the politeness of the |
|
11 user not to "break into the definition." The most important features of classes |
|
12 are retained with full power, however: the class inheritance mechanism allows |
|
13 multiple base classes, a derived class can override any methods of its base |
|
14 class or classes, and a method can call the method of a base class with the same |
|
15 name. Objects can contain an arbitrary amount of private data. |
|
16 |
|
17 In C++ terminology, all class members (including the data members) are *public*, |
|
18 and all member functions are *virtual*. There are no special constructors or |
|
19 destructors. As in Modula-3, there are no shorthands for referencing the |
|
20 object's members from its methods: the method function is declared with an |
|
21 explicit first argument representing the object, which is provided implicitly by |
|
22 the call. As in Smalltalk, classes themselves are objects, albeit in the wider |
|
23 sense of the word: in Python, all data types are objects. This provides |
|
24 semantics for importing and renaming. Unlike C++ and Modula-3, built-in types |
|
25 can be used as base classes for extension by the user. Also, like in C++ but |
|
26 unlike in Modula-3, most built-in operators with special syntax (arithmetic |
|
27 operators, subscripting etc.) can be redefined for class instances. |
|
28 |
|
29 |
|
30 .. _tut-terminology: |
|
31 |
|
32 A Word About Terminology |
|
33 ======================== |
|
34 |
|
35 Lacking universally accepted terminology to talk about classes, I will make |
|
36 occasional use of Smalltalk and C++ terms. (I would use Modula-3 terms, since |
|
37 its object-oriented semantics are closer to those of Python than C++, but I |
|
38 expect that few readers have heard of it.) |
|
39 |
|
40 Objects have individuality, and multiple names (in multiple scopes) can be bound |
|
41 to the same object. This is known as aliasing in other languages. This is |
|
42 usually not appreciated on a first glance at Python, and can be safely ignored |
|
43 when dealing with immutable basic types (numbers, strings, tuples). However, |
|
44 aliasing has an (intended!) effect on the semantics of Python code involving |
|
45 mutable objects such as lists, dictionaries, and most types representing |
|
46 entities outside the program (files, windows, etc.). This is usually used to |
|
47 the benefit of the program, since aliases behave like pointers in some respects. |
|
48 For example, passing an object is cheap since only a pointer is passed by the |
|
49 implementation; and if a function modifies an object passed as an argument, the |
|
50 caller will see the change --- this eliminates the need for two different |
|
51 argument passing mechanisms as in Pascal. |
|
52 |
|
53 |
|
54 .. _tut-scopes: |
|
55 |
|
56 Python Scopes and Name Spaces |
|
57 ============================= |
|
58 |
|
59 Before introducing classes, I first have to tell you something about Python's |
|
60 scope rules. Class definitions play some neat tricks with namespaces, and you |
|
61 need to know how scopes and namespaces work to fully understand what's going on. |
|
62 Incidentally, knowledge about this subject is useful for any advanced Python |
|
63 programmer. |
|
64 |
|
65 Let's begin with some definitions. |
|
66 |
|
67 A *namespace* is a mapping from names to objects. Most namespaces are currently |
|
68 implemented as Python dictionaries, but that's normally not noticeable in any |
|
69 way (except for performance), and it may change in the future. Examples of |
|
70 namespaces are: the set of built-in names (functions such as :func:`abs`, and |
|
71 built-in exception names); the global names in a module; and the local names in |
|
72 a function invocation. In a sense the set of attributes of an object also form |
|
73 a namespace. The important thing to know about namespaces is that there is |
|
74 absolutely no relation between names in different namespaces; for instance, two |
|
75 different modules may both define a function "maximize" without confusion --- |
|
76 users of the modules must prefix it with the module name. |
|
77 |
|
78 By the way, I use the word *attribute* for any name following a dot --- for |
|
79 example, in the expression ``z.real``, ``real`` is an attribute of the object |
|
80 ``z``. Strictly speaking, references to names in modules are attribute |
|
81 references: in the expression ``modname.funcname``, ``modname`` is a module |
|
82 object and ``funcname`` is an attribute of it. In this case there happens to be |
|
83 a straightforward mapping between the module's attributes and the global names |
|
84 defined in the module: they share the same namespace! [#]_ |
|
85 |
|
86 Attributes may be read-only or writable. In the latter case, assignment to |
|
87 attributes is possible. Module attributes are writable: you can write |
|
88 ``modname.the_answer = 42``. Writable attributes may also be deleted with the |
|
89 :keyword:`del` statement. For example, ``del modname.the_answer`` will remove |
|
90 the attribute :attr:`the_answer` from the object named by ``modname``. |
|
91 |
|
92 Name spaces are created at different moments and have different lifetimes. The |
|
93 namespace containing the built-in names is created when the Python interpreter |
|
94 starts up, and is never deleted. The global namespace for a module is created |
|
95 when the module definition is read in; normally, module namespaces also last |
|
96 until the interpreter quits. The statements executed by the top-level |
|
97 invocation of the interpreter, either read from a script file or interactively, |
|
98 are considered part of a module called :mod:`__main__`, so they have their own |
|
99 global namespace. (The built-in names actually also live in a module; this is |
|
100 called :mod:`__builtin__`.) |
|
101 |
|
102 The local namespace for a function is created when the function is called, and |
|
103 deleted when the function returns or raises an exception that is not handled |
|
104 within the function. (Actually, forgetting would be a better way to describe |
|
105 what actually happens.) Of course, recursive invocations each have their own |
|
106 local namespace. |
|
107 |
|
108 A *scope* is a textual region of a Python program where a namespace is directly |
|
109 accessible. "Directly accessible" here means that an unqualified reference to a |
|
110 name attempts to find the name in the namespace. |
|
111 |
|
112 Although scopes are determined statically, they are used dynamically. At any |
|
113 time during execution, there are at least three nested scopes whose namespaces |
|
114 are directly accessible: the innermost scope, which is searched first, contains |
|
115 the local names; the namespaces of any enclosing functions, which are searched |
|
116 starting with the nearest enclosing scope; the middle scope, searched next, |
|
117 contains the current module's global names; and the outermost scope (searched |
|
118 last) is the namespace containing built-in names. |
|
119 |
|
120 If a name is declared global, then all references and assignments go directly to |
|
121 the middle scope containing the module's global names. Otherwise, all variables |
|
122 found outside of the innermost scope are read-only (an attempt to write to such |
|
123 a variable will simply create a *new* local variable in the innermost scope, |
|
124 leaving the identically named outer variable unchanged). |
|
125 |
|
126 Usually, the local scope references the local names of the (textually) current |
|
127 function. Outside functions, the local scope references the same namespace as |
|
128 the global scope: the module's namespace. Class definitions place yet another |
|
129 namespace in the local scope. |
|
130 |
|
131 It is important to realize that scopes are determined textually: the global |
|
132 scope of a function defined in a module is that module's namespace, no matter |
|
133 from where or by what alias the function is called. On the other hand, the |
|
134 actual search for names is done dynamically, at run time --- however, the |
|
135 language definition is evolving towards static name resolution, at "compile" |
|
136 time, so don't rely on dynamic name resolution! (In fact, local variables are |
|
137 already determined statically.) |
|
138 |
|
139 A special quirk of Python is that -- if no :keyword:`global` |
|
140 statement is in effect -- assignments to names always go |
|
141 into the innermost scope. Assignments do not copy data --- they just bind names |
|
142 to objects. The same is true for deletions: the statement ``del x`` removes the |
|
143 binding of ``x`` from the namespace referenced by the local scope. In fact, all |
|
144 operations that introduce new names use the local scope: in particular, import |
|
145 statements and function definitions bind the module or function name in the |
|
146 local scope. (The :keyword:`global` statement can be used to indicate that |
|
147 particular variables live in the global scope.) |
|
148 |
|
149 |
|
150 .. _tut-firstclasses: |
|
151 |
|
152 A First Look at Classes |
|
153 ======================= |
|
154 |
|
155 Classes introduce a little bit of new syntax, three new object types, and some |
|
156 new semantics. |
|
157 |
|
158 |
|
159 .. _tut-classdefinition: |
|
160 |
|
161 Class Definition Syntax |
|
162 ----------------------- |
|
163 |
|
164 The simplest form of class definition looks like this:: |
|
165 |
|
166 class ClassName: |
|
167 <statement-1> |
|
168 . |
|
169 . |
|
170 . |
|
171 <statement-N> |
|
172 |
|
173 Class definitions, like function definitions (:keyword:`def` statements) must be |
|
174 executed before they have any effect. (You could conceivably place a class |
|
175 definition in a branch of an :keyword:`if` statement, or inside a function.) |
|
176 |
|
177 In practice, the statements inside a class definition will usually be function |
|
178 definitions, but other statements are allowed, and sometimes useful --- we'll |
|
179 come back to this later. The function definitions inside a class normally have |
|
180 a peculiar form of argument list, dictated by the calling conventions for |
|
181 methods --- again, this is explained later. |
|
182 |
|
183 When a class definition is entered, a new namespace is created, and used as the |
|
184 local scope --- thus, all assignments to local variables go into this new |
|
185 namespace. In particular, function definitions bind the name of the new |
|
186 function here. |
|
187 |
|
188 When a class definition is left normally (via the end), a *class object* is |
|
189 created. This is basically a wrapper around the contents of the namespace |
|
190 created by the class definition; we'll learn more about class objects in the |
|
191 next section. The original local scope (the one in effect just before the class |
|
192 definition was entered) is reinstated, and the class object is bound here to the |
|
193 class name given in the class definition header (:class:`ClassName` in the |
|
194 example). |
|
195 |
|
196 |
|
197 .. _tut-classobjects: |
|
198 |
|
199 Class Objects |
|
200 ------------- |
|
201 |
|
202 Class objects support two kinds of operations: attribute references and |
|
203 instantiation. |
|
204 |
|
205 *Attribute references* use the standard syntax used for all attribute references |
|
206 in Python: ``obj.name``. Valid attribute names are all the names that were in |
|
207 the class's namespace when the class object was created. So, if the class |
|
208 definition looked like this:: |
|
209 |
|
210 class MyClass: |
|
211 """A simple example class""" |
|
212 i = 12345 |
|
213 def f(self): |
|
214 return 'hello world' |
|
215 |
|
216 then ``MyClass.i`` and ``MyClass.f`` are valid attribute references, returning |
|
217 an integer and a function object, respectively. Class attributes can also be |
|
218 assigned to, so you can change the value of ``MyClass.i`` by assignment. |
|
219 :attr:`__doc__` is also a valid attribute, returning the docstring belonging to |
|
220 the class: ``"A simple example class"``. |
|
221 |
|
222 Class *instantiation* uses function notation. Just pretend that the class |
|
223 object is a parameterless function that returns a new instance of the class. |
|
224 For example (assuming the above class):: |
|
225 |
|
226 x = MyClass() |
|
227 |
|
228 creates a new *instance* of the class and assigns this object to the local |
|
229 variable ``x``. |
|
230 |
|
231 The instantiation operation ("calling" a class object) creates an empty object. |
|
232 Many classes like to create objects with instances customized to a specific |
|
233 initial state. Therefore a class may define a special method named |
|
234 :meth:`__init__`, like this:: |
|
235 |
|
236 def __init__(self): |
|
237 self.data = [] |
|
238 |
|
239 When a class defines an :meth:`__init__` method, class instantiation |
|
240 automatically invokes :meth:`__init__` for the newly-created class instance. So |
|
241 in this example, a new, initialized instance can be obtained by:: |
|
242 |
|
243 x = MyClass() |
|
244 |
|
245 Of course, the :meth:`__init__` method may have arguments for greater |
|
246 flexibility. In that case, arguments given to the class instantiation operator |
|
247 are passed on to :meth:`__init__`. For example, :: |
|
248 |
|
249 >>> class Complex: |
|
250 ... def __init__(self, realpart, imagpart): |
|
251 ... self.r = realpart |
|
252 ... self.i = imagpart |
|
253 ... |
|
254 >>> x = Complex(3.0, -4.5) |
|
255 >>> x.r, x.i |
|
256 (3.0, -4.5) |
|
257 |
|
258 |
|
259 .. _tut-instanceobjects: |
|
260 |
|
261 Instance Objects |
|
262 ---------------- |
|
263 |
|
264 Now what can we do with instance objects? The only operations understood by |
|
265 instance objects are attribute references. There are two kinds of valid |
|
266 attribute names, data attributes and methods. |
|
267 |
|
268 *data attributes* correspond to "instance variables" in Smalltalk, and to "data |
|
269 members" in C++. Data attributes need not be declared; like local variables, |
|
270 they spring into existence when they are first assigned to. For example, if |
|
271 ``x`` is the instance of :class:`MyClass` created above, the following piece of |
|
272 code will print the value ``16``, without leaving a trace:: |
|
273 |
|
274 x.counter = 1 |
|
275 while x.counter < 10: |
|
276 x.counter = x.counter * 2 |
|
277 print x.counter |
|
278 del x.counter |
|
279 |
|
280 The other kind of instance attribute reference is a *method*. A method is a |
|
281 function that "belongs to" an object. (In Python, the term method is not unique |
|
282 to class instances: other object types can have methods as well. For example, |
|
283 list objects have methods called append, insert, remove, sort, and so on. |
|
284 However, in the following discussion, we'll use the term method exclusively to |
|
285 mean methods of class instance objects, unless explicitly stated otherwise.) |
|
286 |
|
287 .. index:: object: method |
|
288 |
|
289 Valid method names of an instance object depend on its class. By definition, |
|
290 all attributes of a class that are function objects define corresponding |
|
291 methods of its instances. So in our example, ``x.f`` is a valid method |
|
292 reference, since ``MyClass.f`` is a function, but ``x.i`` is not, since |
|
293 ``MyClass.i`` is not. But ``x.f`` is not the same thing as ``MyClass.f`` --- it |
|
294 is a *method object*, not a function object. |
|
295 |
|
296 |
|
297 .. _tut-methodobjects: |
|
298 |
|
299 Method Objects |
|
300 -------------- |
|
301 |
|
302 Usually, a method is called right after it is bound:: |
|
303 |
|
304 x.f() |
|
305 |
|
306 In the :class:`MyClass` example, this will return the string ``'hello world'``. |
|
307 However, it is not necessary to call a method right away: ``x.f`` is a method |
|
308 object, and can be stored away and called at a later time. For example:: |
|
309 |
|
310 xf = x.f |
|
311 while True: |
|
312 print xf() |
|
313 |
|
314 will continue to print ``hello world`` until the end of time. |
|
315 |
|
316 What exactly happens when a method is called? You may have noticed that |
|
317 ``x.f()`` was called without an argument above, even though the function |
|
318 definition for :meth:`f` specified an argument. What happened to the argument? |
|
319 Surely Python raises an exception when a function that requires an argument is |
|
320 called without any --- even if the argument isn't actually used... |
|
321 |
|
322 Actually, you may have guessed the answer: the special thing about methods is |
|
323 that the object is passed as the first argument of the function. In our |
|
324 example, the call ``x.f()`` is exactly equivalent to ``MyClass.f(x)``. In |
|
325 general, calling a method with a list of *n* arguments is equivalent to calling |
|
326 the corresponding function with an argument list that is created by inserting |
|
327 the method's object before the first argument. |
|
328 |
|
329 If you still don't understand how methods work, a look at the implementation can |
|
330 perhaps clarify matters. When an instance attribute is referenced that isn't a |
|
331 data attribute, its class is searched. If the name denotes a valid class |
|
332 attribute that is a function object, a method object is created by packing |
|
333 (pointers to) the instance object and the function object just found together in |
|
334 an abstract object: this is the method object. When the method object is called |
|
335 with an argument list, it is unpacked again, a new argument list is constructed |
|
336 from the instance object and the original argument list, and the function object |
|
337 is called with this new argument list. |
|
338 |
|
339 |
|
340 .. _tut-remarks: |
|
341 |
|
342 Random Remarks |
|
343 ============== |
|
344 |
|
345 .. These should perhaps be placed more carefully... |
|
346 |
|
347 Data attributes override method attributes with the same name; to avoid |
|
348 accidental name conflicts, which may cause hard-to-find bugs in large programs, |
|
349 it is wise to use some kind of convention that minimizes the chance of |
|
350 conflicts. Possible conventions include capitalizing method names, prefixing |
|
351 data attribute names with a small unique string (perhaps just an underscore), or |
|
352 using verbs for methods and nouns for data attributes. |
|
353 |
|
354 Data attributes may be referenced by methods as well as by ordinary users |
|
355 ("clients") of an object. In other words, classes are not usable to implement |
|
356 pure abstract data types. In fact, nothing in Python makes it possible to |
|
357 enforce data hiding --- it is all based upon convention. (On the other hand, |
|
358 the Python implementation, written in C, can completely hide implementation |
|
359 details and control access to an object if necessary; this can be used by |
|
360 extensions to Python written in C.) |
|
361 |
|
362 Clients should use data attributes with care --- clients may mess up invariants |
|
363 maintained by the methods by stamping on their data attributes. Note that |
|
364 clients may add data attributes of their own to an instance object without |
|
365 affecting the validity of the methods, as long as name conflicts are avoided --- |
|
366 again, a naming convention can save a lot of headaches here. |
|
367 |
|
368 There is no shorthand for referencing data attributes (or other methods!) from |
|
369 within methods. I find that this actually increases the readability of methods: |
|
370 there is no chance of confusing local variables and instance variables when |
|
371 glancing through a method. |
|
372 |
|
373 Often, the first argument of a method is called ``self``. This is nothing more |
|
374 than a convention: the name ``self`` has absolutely no special meaning to |
|
375 Python. (Note, however, that by not following the convention your code may be |
|
376 less readable to other Python programmers, and it is also conceivable that a |
|
377 *class browser* program might be written that relies upon such a convention.) |
|
378 |
|
379 Any function object that is a class attribute defines a method for instances of |
|
380 that class. It is not necessary that the function definition is textually |
|
381 enclosed in the class definition: assigning a function object to a local |
|
382 variable in the class is also ok. For example:: |
|
383 |
|
384 # Function defined outside the class |
|
385 def f1(self, x, y): |
|
386 return min(x, x+y) |
|
387 |
|
388 class C: |
|
389 f = f1 |
|
390 def g(self): |
|
391 return 'hello world' |
|
392 h = g |
|
393 |
|
394 Now ``f``, ``g`` and ``h`` are all attributes of class :class:`C` that refer to |
|
395 function objects, and consequently they are all methods of instances of |
|
396 :class:`C` --- ``h`` being exactly equivalent to ``g``. Note that this practice |
|
397 usually only serves to confuse the reader of a program. |
|
398 |
|
399 Methods may call other methods by using method attributes of the ``self`` |
|
400 argument:: |
|
401 |
|
402 class Bag: |
|
403 def __init__(self): |
|
404 self.data = [] |
|
405 def add(self, x): |
|
406 self.data.append(x) |
|
407 def addtwice(self, x): |
|
408 self.add(x) |
|
409 self.add(x) |
|
410 |
|
411 Methods may reference global names in the same way as ordinary functions. The |
|
412 global scope associated with a method is the module containing the class |
|
413 definition. (The class itself is never used as a global scope!) While one |
|
414 rarely encounters a good reason for using global data in a method, there are |
|
415 many legitimate uses of the global scope: for one thing, functions and modules |
|
416 imported into the global scope can be used by methods, as well as functions and |
|
417 classes defined in it. Usually, the class containing the method is itself |
|
418 defined in this global scope, and in the next section we'll find some good |
|
419 reasons why a method would want to reference its own class! |
|
420 |
|
421 Each value is an object, and therefore has a *class* (also called its *type*). |
|
422 It is stored as ``object.__class__``. |
|
423 |
|
424 |
|
425 .. _tut-inheritance: |
|
426 |
|
427 Inheritance |
|
428 =========== |
|
429 |
|
430 Of course, a language feature would not be worthy of the name "class" without |
|
431 supporting inheritance. The syntax for a derived class definition looks like |
|
432 this:: |
|
433 |
|
434 class DerivedClassName(BaseClassName): |
|
435 <statement-1> |
|
436 . |
|
437 . |
|
438 . |
|
439 <statement-N> |
|
440 |
|
441 The name :class:`BaseClassName` must be defined in a scope containing the |
|
442 derived class definition. In place of a base class name, other arbitrary |
|
443 expressions are also allowed. This can be useful, for example, when the base |
|
444 class is defined in another module:: |
|
445 |
|
446 class DerivedClassName(modname.BaseClassName): |
|
447 |
|
448 Execution of a derived class definition proceeds the same as for a base class. |
|
449 When the class object is constructed, the base class is remembered. This is |
|
450 used for resolving attribute references: if a requested attribute is not found |
|
451 in the class, the search proceeds to look in the base class. This rule is |
|
452 applied recursively if the base class itself is derived from some other class. |
|
453 |
|
454 There's nothing special about instantiation of derived classes: |
|
455 ``DerivedClassName()`` creates a new instance of the class. Method references |
|
456 are resolved as follows: the corresponding class attribute is searched, |
|
457 descending down the chain of base classes if necessary, and the method reference |
|
458 is valid if this yields a function object. |
|
459 |
|
460 Derived classes may override methods of their base classes. Because methods |
|
461 have no special privileges when calling other methods of the same object, a |
|
462 method of a base class that calls another method defined in the same base class |
|
463 may end up calling a method of a derived class that overrides it. (For C++ |
|
464 programmers: all methods in Python are effectively ``virtual``.) |
|
465 |
|
466 An overriding method in a derived class may in fact want to extend rather than |
|
467 simply replace the base class method of the same name. There is a simple way to |
|
468 call the base class method directly: just call ``BaseClassName.methodname(self, |
|
469 arguments)``. This is occasionally useful to clients as well. (Note that this |
|
470 only works if the base class is defined or imported directly in the global |
|
471 scope.) |
|
472 |
|
473 Python has two builtin functions that work with inheritance: |
|
474 |
|
475 * Use :func:`isinstance` to check an object's type: ``isinstance(obj, int)`` |
|
476 will be ``True`` only if ``obj.__class__`` is :class:`int` or some class |
|
477 derived from :class:`int`. |
|
478 |
|
479 * Use :func:`issubclass` to check class inheritance: ``issubclass(bool, int)`` |
|
480 is ``True`` since :class:`bool` is a subclass of :class:`int`. However, |
|
481 ``issubclass(unicode, str)`` is ``False`` since :class:`unicode` is not a |
|
482 subclass of :class:`str` (they only share a common ancestor, |
|
483 :class:`basestring`). |
|
484 |
|
485 |
|
486 |
|
487 .. _tut-multiple: |
|
488 |
|
489 Multiple Inheritance |
|
490 -------------------- |
|
491 |
|
492 Python supports a limited form of multiple inheritance as well. A class |
|
493 definition with multiple base classes looks like this:: |
|
494 |
|
495 class DerivedClassName(Base1, Base2, Base3): |
|
496 <statement-1> |
|
497 . |
|
498 . |
|
499 . |
|
500 <statement-N> |
|
501 |
|
502 For old-style classes, the only rule is depth-first, left-to-right. Thus, if an |
|
503 attribute is not found in :class:`DerivedClassName`, it is searched in |
|
504 :class:`Base1`, then (recursively) in the base classes of :class:`Base1`, and |
|
505 only if it is not found there, it is searched in :class:`Base2`, and so on. |
|
506 |
|
507 (To some people breadth first --- searching :class:`Base2` and :class:`Base3` |
|
508 before the base classes of :class:`Base1` --- looks more natural. However, this |
|
509 would require you to know whether a particular attribute of :class:`Base1` is |
|
510 actually defined in :class:`Base1` or in one of its base classes before you can |
|
511 figure out the consequences of a name conflict with an attribute of |
|
512 :class:`Base2`. The depth-first rule makes no differences between direct and |
|
513 inherited attributes of :class:`Base1`.) |
|
514 |
|
515 For :term:`new-style class`\es, the method resolution order changes dynamically |
|
516 to support cooperative calls to :func:`super`. This approach is known in some |
|
517 other multiple-inheritance languages as call-next-method and is more powerful |
|
518 than the super call found in single-inheritance languages. |
|
519 |
|
520 With new-style classes, dynamic ordering is necessary because all cases of |
|
521 multiple inheritance exhibit one or more diamond relationships (where one at |
|
522 least one of the parent classes can be accessed through multiple paths from the |
|
523 bottommost class). For example, all new-style classes inherit from |
|
524 :class:`object`, so any case of multiple inheritance provides more than one path |
|
525 to reach :class:`object`. To keep the base classes from being accessed more |
|
526 than once, the dynamic algorithm linearizes the search order in a way that |
|
527 preserves the left-to-right ordering specified in each class, that calls each |
|
528 parent only once, and that is monotonic (meaning that a class can be subclassed |
|
529 without affecting the precedence order of its parents). Taken together, these |
|
530 properties make it possible to design reliable and extensible classes with |
|
531 multiple inheritance. For more detail, see |
|
532 http://www.python.org/download/releases/2.3/mro/. |
|
533 |
|
534 |
|
535 .. _tut-private: |
|
536 |
|
537 Private Variables |
|
538 ================= |
|
539 |
|
540 There is limited support for class-private identifiers. Any identifier of the |
|
541 form ``__spam`` (at least two leading underscores, at most one trailing |
|
542 underscore) is textually replaced with ``_classname__spam``, where ``classname`` |
|
543 is the current class name with leading underscore(s) stripped. This mangling is |
|
544 done without regard to the syntactic position of the identifier, so it can be |
|
545 used to define class-private instance and class variables, methods, variables |
|
546 stored in globals, and even variables stored in instances. private to this class |
|
547 on instances of *other* classes. Truncation may occur when the mangled name |
|
548 would be longer than 255 characters. Outside classes, or when the class name |
|
549 consists of only underscores, no mangling occurs. |
|
550 |
|
551 Name mangling is intended to give classes an easy way to define "private" |
|
552 instance variables and methods, without having to worry about instance variables |
|
553 defined by derived classes, or mucking with instance variables by code outside |
|
554 the class. Note that the mangling rules are designed mostly to avoid accidents; |
|
555 it still is possible for a determined soul to access or modify a variable that |
|
556 is considered private. This can even be useful in special circumstances, such |
|
557 as in the debugger, and that's one reason why this loophole is not closed. |
|
558 (Buglet: derivation of a class with the same name as the base class makes use of |
|
559 private variables of the base class possible.) |
|
560 |
|
561 Notice that code passed to ``exec``, ``eval()`` or ``execfile()`` does not |
|
562 consider the classname of the invoking class to be the current class; this is |
|
563 similar to the effect of the ``global`` statement, the effect of which is |
|
564 likewise restricted to code that is byte-compiled together. The same |
|
565 restriction applies to ``getattr()``, ``setattr()`` and ``delattr()``, as well |
|
566 as when referencing ``__dict__`` directly. |
|
567 |
|
568 |
|
569 .. _tut-odds: |
|
570 |
|
571 Odds and Ends |
|
572 ============= |
|
573 |
|
574 Sometimes it is useful to have a data type similar to the Pascal "record" or C |
|
575 "struct", bundling together a few named data items. An empty class definition |
|
576 will do nicely:: |
|
577 |
|
578 class Employee: |
|
579 pass |
|
580 |
|
581 john = Employee() # Create an empty employee record |
|
582 |
|
583 # Fill the fields of the record |
|
584 john.name = 'John Doe' |
|
585 john.dept = 'computer lab' |
|
586 john.salary = 1000 |
|
587 |
|
588 A piece of Python code that expects a particular abstract data type can often be |
|
589 passed a class that emulates the methods of that data type instead. For |
|
590 instance, if you have a function that formats some data from a file object, you |
|
591 can define a class with methods :meth:`read` and :meth:`readline` that get the |
|
592 data from a string buffer instead, and pass it as an argument. |
|
593 |
|
594 .. (Unfortunately, this technique has its limitations: a class can't define |
|
595 operations that are accessed by special syntax such as sequence subscripting |
|
596 or arithmetic operators, and assigning such a "pseudo-file" to sys.stdin will |
|
597 not cause the interpreter to read further input from it.) |
|
598 |
|
599 Instance method objects have attributes, too: ``m.im_self`` is the instance |
|
600 object with the method :meth:`m`, and ``m.im_func`` is the function object |
|
601 corresponding to the method. |
|
602 |
|
603 |
|
604 .. _tut-exceptionclasses: |
|
605 |
|
606 Exceptions Are Classes Too |
|
607 ========================== |
|
608 |
|
609 User-defined exceptions are identified by classes as well. Using this mechanism |
|
610 it is possible to create extensible hierarchies of exceptions. |
|
611 |
|
612 There are two new valid (semantic) forms for the raise statement:: |
|
613 |
|
614 raise Class, instance |
|
615 |
|
616 raise instance |
|
617 |
|
618 In the first form, ``instance`` must be an instance of :class:`Class` or of a |
|
619 class derived from it. The second form is a shorthand for:: |
|
620 |
|
621 raise instance.__class__, instance |
|
622 |
|
623 A class in an except clause is compatible with an exception if it is the same |
|
624 class or a base class thereof (but not the other way around --- an except clause |
|
625 listing a derived class is not compatible with a base class). For example, the |
|
626 following code will print B, C, D in that order:: |
|
627 |
|
628 class B: |
|
629 pass |
|
630 class C(B): |
|
631 pass |
|
632 class D(C): |
|
633 pass |
|
634 |
|
635 for c in [B, C, D]: |
|
636 try: |
|
637 raise c() |
|
638 except D: |
|
639 print "D" |
|
640 except C: |
|
641 print "C" |
|
642 except B: |
|
643 print "B" |
|
644 |
|
645 Note that if the except clauses were reversed (with ``except B`` first), it |
|
646 would have printed B, B, B --- the first matching except clause is triggered. |
|
647 |
|
648 When an error message is printed for an unhandled exception, the exception's |
|
649 class name is printed, then a colon and a space, and finally the instance |
|
650 converted to a string using the built-in function :func:`str`. |
|
651 |
|
652 |
|
653 .. _tut-iterators: |
|
654 |
|
655 Iterators |
|
656 ========= |
|
657 |
|
658 By now you have probably noticed that most container objects can be looped over |
|
659 using a :keyword:`for` statement:: |
|
660 |
|
661 for element in [1, 2, 3]: |
|
662 print element |
|
663 for element in (1, 2, 3): |
|
664 print element |
|
665 for key in {'one':1, 'two':2}: |
|
666 print key |
|
667 for char in "123": |
|
668 print char |
|
669 for line in open("myfile.txt"): |
|
670 print line |
|
671 |
|
672 This style of access is clear, concise, and convenient. The use of iterators |
|
673 pervades and unifies Python. Behind the scenes, the :keyword:`for` statement |
|
674 calls :func:`iter` on the container object. The function returns an iterator |
|
675 object that defines the method :meth:`next` which accesses elements in the |
|
676 container one at a time. When there are no more elements, :meth:`next` raises a |
|
677 :exc:`StopIteration` exception which tells the :keyword:`for` loop to terminate. |
|
678 This example shows how it all works:: |
|
679 |
|
680 >>> s = 'abc' |
|
681 >>> it = iter(s) |
|
682 >>> it |
|
683 <iterator object at 0x00A1DB50> |
|
684 >>> it.next() |
|
685 'a' |
|
686 >>> it.next() |
|
687 'b' |
|
688 >>> it.next() |
|
689 'c' |
|
690 >>> it.next() |
|
691 |
|
692 Traceback (most recent call last): |
|
693 File "<stdin>", line 1, in ? |
|
694 it.next() |
|
695 StopIteration |
|
696 |
|
697 Having seen the mechanics behind the iterator protocol, it is easy to add |
|
698 iterator behavior to your classes. Define a :meth:`__iter__` method which |
|
699 returns an object with a :meth:`next` method. If the class defines |
|
700 :meth:`next`, then :meth:`__iter__` can just return ``self``:: |
|
701 |
|
702 class Reverse: |
|
703 "Iterator for looping over a sequence backwards" |
|
704 def __init__(self, data): |
|
705 self.data = data |
|
706 self.index = len(data) |
|
707 def __iter__(self): |
|
708 return self |
|
709 def next(self): |
|
710 if self.index == 0: |
|
711 raise StopIteration |
|
712 self.index = self.index - 1 |
|
713 return self.data[self.index] |
|
714 |
|
715 >>> for char in Reverse('spam'): |
|
716 ... print char |
|
717 ... |
|
718 m |
|
719 a |
|
720 p |
|
721 s |
|
722 |
|
723 |
|
724 .. _tut-generators: |
|
725 |
|
726 Generators |
|
727 ========== |
|
728 |
|
729 :term:`Generator`\s are a simple and powerful tool for creating iterators. They |
|
730 are written like regular functions but use the :keyword:`yield` statement |
|
731 whenever they want to return data. Each time :meth:`next` is called, the |
|
732 generator resumes where it left-off (it remembers all the data values and which |
|
733 statement was last executed). An example shows that generators can be trivially |
|
734 easy to create:: |
|
735 |
|
736 def reverse(data): |
|
737 for index in range(len(data)-1, -1, -1): |
|
738 yield data[index] |
|
739 |
|
740 >>> for char in reverse('golf'): |
|
741 ... print char |
|
742 ... |
|
743 f |
|
744 l |
|
745 o |
|
746 g |
|
747 |
|
748 Anything that can be done with generators can also be done with class based |
|
749 iterators as described in the previous section. What makes generators so |
|
750 compact is that the :meth:`__iter__` and :meth:`next` methods are created |
|
751 automatically. |
|
752 |
|
753 Another key feature is that the local variables and execution state are |
|
754 automatically saved between calls. This made the function easier to write and |
|
755 much more clear than an approach using instance variables like ``self.index`` |
|
756 and ``self.data``. |
|
757 |
|
758 In addition to automatic method creation and saving program state, when |
|
759 generators terminate, they automatically raise :exc:`StopIteration`. In |
|
760 combination, these features make it easy to create iterators with no more effort |
|
761 than writing a regular function. |
|
762 |
|
763 |
|
764 .. _tut-genexps: |
|
765 |
|
766 Generator Expressions |
|
767 ===================== |
|
768 |
|
769 Some simple generators can be coded succinctly as expressions using a syntax |
|
770 similar to list comprehensions but with parentheses instead of brackets. These |
|
771 expressions are designed for situations where the generator is used right away |
|
772 by an enclosing function. Generator expressions are more compact but less |
|
773 versatile than full generator definitions and tend to be more memory friendly |
|
774 than equivalent list comprehensions. |
|
775 |
|
776 Examples:: |
|
777 |
|
778 >>> sum(i*i for i in range(10)) # sum of squares |
|
779 285 |
|
780 |
|
781 >>> xvec = [10, 20, 30] |
|
782 >>> yvec = [7, 5, 3] |
|
783 >>> sum(x*y for x,y in zip(xvec, yvec)) # dot product |
|
784 260 |
|
785 |
|
786 >>> from math import pi, sin |
|
787 >>> sine_table = dict((x, sin(x*pi/180)) for x in range(0, 91)) |
|
788 |
|
789 >>> unique_words = set(word for line in page for word in line.split()) |
|
790 |
|
791 >>> valedictorian = max((student.gpa, student.name) for student in graduates) |
|
792 |
|
793 >>> data = 'golf' |
|
794 >>> list(data[i] for i in range(len(data)-1,-1,-1)) |
|
795 ['f', 'l', 'o', 'g'] |
|
796 |
|
797 |
|
798 |
|
799 .. rubric:: Footnotes |
|
800 |
|
801 .. [#] Except for one thing. Module objects have a secret read-only attribute called |
|
802 :attr:`__dict__` which returns the dictionary used to implement the module's |
|
803 namespace; the name :attr:`__dict__` is an attribute but not a global name. |
|
804 Obviously, using this violates the abstraction of namespace implementation, and |
|
805 should be restricted to things like post-mortem debuggers. |
|
806 |