Guido van Rossum | 1fb071c | 1997-08-25 21:36:44 +0000 | [diff] [blame] | 1 | <HTML> |
| 2 | |
| 3 | <HEAD> |
| 4 | <TITLE>Metaprogramming in Python 1.5</TITLE> |
| 5 | </HEAD> |
| 6 | |
| 7 | <BODY BGCOLOR="FFFFFF"> |
| 8 | |
Guido van Rossum | 0cdb887 | 1997-08-26 00:08:51 +0000 | [diff] [blame^] | 9 | <H1>Metaprogramming in Python 1.5 (DRAFT)</H1> |
Guido van Rossum | 1fb071c | 1997-08-25 21:36:44 +0000 | [diff] [blame] | 10 | |
Guido van Rossum | 0cdb887 | 1997-08-26 00:08:51 +0000 | [diff] [blame^] | 11 | <H4>XXX This is very much a work in progress.</H4> |
Guido van Rossum | 1fb071c | 1997-08-25 21:36:44 +0000 | [diff] [blame] | 12 | |
| 13 | <P>While Python 1.5 is only out as a <A |
| 14 | HREF="http://grail.cnri.reston.va.us/python/1.5a3/">restricted alpha |
| 15 | release</A>, its metaprogramming feature is worth mentioning. |
| 16 | |
| 17 | <P>In previous Python releases (and still in 1.5), there is something |
| 18 | called the ``Don Beaudry hook'', after its inventor and champion. |
| 19 | This allows C extensions to provide alternate class behavior, thereby |
| 20 | allowing the Python class syntax to be used to define other class-like |
| 21 | entities. Don Beaudry has used this in his infamous <A |
| 22 | HREF="http://maigret.cog.brown.edu/pyutil/">MESS</A> package; Jim |
| 23 | Fulton has used it in his <A |
| 24 | HREF="http://www.digicool.com/papers/ExtensionClass.html">Extension |
| 25 | Classes</A> package. (It has also been referred to as the ``Don |
| 26 | Beaudry <i>hack</i>, but that's a misnomer. There's nothing hackish |
| 27 | about it -- in fact, it is rather elegant and deep, even though |
| 28 | there's something dark to it.) |
| 29 | |
| 30 | <P>Documentation of the Don Beaudry hook has purposefully been kept |
| 31 | minimal, since it is a feature of incredible power, and is easily |
| 32 | abused. Basically, it checks whether the <b>type of the base |
| 33 | class</b> is callable, and if so, it is called to create the new |
| 34 | class. |
| 35 | |
| 36 | <P>Note the two indirection levels. Take a simple example: |
| 37 | |
| 38 | <PRE> |
| 39 | class B: |
| 40 | pass |
| 41 | |
| 42 | class C(B): |
| 43 | pass |
| 44 | </PRE> |
| 45 | |
| 46 | Take a look at the second class definition, and try to fathom ``the |
| 47 | type of the base class is callable.'' |
| 48 | |
| 49 | <P>(Types are not classes, by the way. See questions 4.2, 4.19 and in |
| 50 | particular 6.22 in the <A |
| 51 | HREF="http://grail.cnri.reston.va.us/cgi-bin/faqw.py" >Python FAQ</A> |
| 52 | for more on this topic.) |
| 53 | |
| 54 | <P> |
| 55 | |
| 56 | <UL> |
| 57 | |
| 58 | <LI>The <b>base class</b> is B; this one's easy.<P> |
| 59 | |
| 60 | <LI>Since B is a class, its type is ``class''; so the <b>type of the |
| 61 | base class</b> is the type ``class''. This is also known as |
| 62 | types.ClassType, assuming the standard module <code>types</code> has |
| 63 | been imported.<P> |
| 64 | |
| 65 | <LI>Now is the type ``class'' <b>callable</b>? No, because types (in |
| 66 | core Python) are never callable. Classes are callable (calling a |
| 67 | class creates a new instance) but types aren't.<P> |
| 68 | |
| 69 | </UL> |
| 70 | |
| 71 | <P>So our conclusion is that in our example, the type of the base |
| 72 | class (of C) is not callable. So the Don Beaudry hook does not apply, |
| 73 | and the default class creation mechanism is used (which is also used |
| 74 | when there is no base class). In fact, the Don Beaudry hook never |
| 75 | applies when using only core Python, since the type of a core object |
| 76 | is never callable. |
| 77 | |
| 78 | <P>So what do Don and Jim do in order to use Don's hook? Write an |
| 79 | extension that defines at least two new Python object types. The |
| 80 | first would be the type for ``class-like'' objects usable as a base |
| 81 | class, to trigger Don's hook. This type must be made callable. |
| 82 | That's why we need a second type. Whether an object is callable |
| 83 | depends on its type. So whether a type object is callable depends on |
| 84 | <i>its</i> type, which is a <i>meta-type</i>. (In core Python there |
| 85 | is only one meta-type, the type ``type'' (types.TypeType), which is |
| 86 | the type of all type objects, even itself.) A new meta-type must |
| 87 | be defined that makes the type of the class-like objects callable. |
| 88 | (Normally, a third type would also be needed, the new ``instance'' |
| 89 | type, but this is not an absolute requirement -- the new class type |
| 90 | could return an object of some existing type when invoked to create an |
| 91 | instance.) |
| 92 | |
| 93 | <P>Still confused? Here's a simple device due to Don himself to |
| 94 | explain metaclasses. Take a simple class definition; assume B is a |
| 95 | special class that triggers Don's hook: |
| 96 | |
| 97 | <PRE> |
| 98 | class C(B): |
| 99 | a = 1 |
| 100 | b = 2 |
| 101 | </PRE> |
| 102 | |
| 103 | This can be though of as equivalent to: |
| 104 | |
| 105 | <PRE> |
| 106 | C = type(B)('C', (B,), {'a': 1, 'b': 2}) |
| 107 | </PRE> |
| 108 | |
| 109 | If that's too dense for you, here's the same thing written out using |
| 110 | temporary variables: |
| 111 | |
| 112 | <PRE> |
| 113 | creator = type(B) # The type of the base class |
| 114 | name = 'C' # The name of the new class |
| 115 | bases = (B,) # A tuple containing the base class(es) |
| 116 | namespace = {'a': 1, 'b': 2} # The namespace of the class statement |
| 117 | C = creator(name, bases, namespace) |
| 118 | </PRE> |
| 119 | |
| 120 | This is analogous to what happens without the Don Beaudry hook, except |
| 121 | that in that case the creator function is set to the default class |
| 122 | creator. |
| 123 | |
| 124 | <P>In either case, the creator is called with three arguments. The |
| 125 | first one, <i>name</i>, is the name of the new class (as given at the |
| 126 | top of the class statement). The <i>bases</i> argument is a tuple of |
| 127 | base classes (a singleton tuple if there's only one base class, like |
| 128 | the example). Finally, <i>namespace</i> is a dictionary containing |
| 129 | the local variables collected during execution of the class statement. |
| 130 | |
| 131 | <P>Note that the contents of the namespace dictionary is simply |
| 132 | whatever names were defined in the class statement. A little-known |
| 133 | fact is that when Python executes a class statement, it enters a new |
| 134 | local namespace, and all assignments and function definitions take |
| 135 | place in this namespace. Thus, after executing the following class |
| 136 | statement: |
| 137 | |
| 138 | <PRE> |
| 139 | class C: |
| 140 | a = 1 |
| 141 | def f(s): pass |
| 142 | </PRE> |
| 143 | |
| 144 | the class namespace's contents would be {'a': 1, 'f': <function f |
| 145 | ...>}. |
| 146 | |
| 147 | <P>But enough already about Python metaprogramming in C; read the |
| 148 | documentation of <A |
| 149 | HREF="http://maigret.cog.brown.edu/pyutil/">MESS</A> or <A |
| 150 | HREF="http://www.digicool.com/papers/ExtensionClass.html" >Extension |
| 151 | Classes</A> for more information. |
| 152 | |
| 153 | <H2>Writing Metaclasses in Python</H2> |
| 154 | |
| 155 | <P>In Python 1.5, the requirement to write a C extension in order to |
| 156 | engage in metaprogramming has been dropped (though you can still do |
| 157 | it, of course). In addition to the check ``is the type of the base |
| 158 | class callable,'' there's a check ``does the base class have a |
| 159 | __class__ attribute.'' If so, it is assumed that the __class__ |
| 160 | attribute refers to a class. |
| 161 | |
| 162 | <P>Let's repeat our simple example from above: |
| 163 | |
| 164 | <PRE> |
| 165 | class C(B): |
| 166 | a = 1 |
| 167 | b = 2 |
| 168 | </PRE> |
| 169 | |
| 170 | Assuming B has a __class__ attribute, this translates into: |
| 171 | |
| 172 | <PRE> |
| 173 | C = B.__class__('C', (B,), {'a': 1, 'b': 2}) |
| 174 | </PRE> |
| 175 | |
| 176 | This is exactly the same as before except that instead of type(B), |
| 177 | B.__class__ is invoked. If you have read <A HREF= |
| 178 | "http://grail.cnri.reston.va.us/cgi-bin/faqw.py?req=show&file=faq06.022.htp" |
| 179 | >FAQ question 6.22</A> you will understand that while there is a big |
| 180 | technical difference between type(B) and B.__class__, they play the |
| 181 | same role at different abstraction levels. And perhaps at some point |
| 182 | in the future they will really be the same thing (at which point you |
| 183 | would be able to derive subclasses from built-in types). |
| 184 | |
| 185 | <P>Going back to the example, the class B.__class__ is instantiated, |
| 186 | passing its constructor the same three arguments that are passed to |
| 187 | the default class constructor or to an extension's metaprogramming |
| 188 | code: <i>name</i>, <i>bases</i>, and <i>namespace</i>. |
| 189 | |
| 190 | <P>It is easy to be confused by what exactly happens when using a |
| 191 | metaclass, because we lose the absolute distinction between classes |
| 192 | and instances: a class is an instance of a metaclass (a |
| 193 | ``metainstance''), but technically (i.e. in the eyes of the python |
| 194 | runtime system), the metaclass is just a class, and the metainstance |
| 195 | is just an instance. At the end of the class statement, the metaclass |
| 196 | whose metainstance is used as a base class is instantiated, yielding a |
| 197 | second metainstance (of the same metaclass). This metainstance is |
| 198 | then used as a (normal, non-meta) class; instantiation of the class |
| 199 | means calling the metainstance, and this will return a real instance. |
| 200 | And what class is that an instance of? Conceptually, it is of course |
| 201 | an instance of our metainstance; but in most cases the Python runtime |
| 202 | system will see it as an instance of a a helper class used by the |
| 203 | metaclass to implement its (non-meta) instances... |
| 204 | |
| 205 | <P>Hopefully an example will make things clearer. Let's presume we |
| 206 | have a metaclass MetaClass1. It's helper class (for non-meta |
| 207 | instances) is callled HelperClass1. We now (manually) instantiate |
| 208 | MetaClass1 once to get an empty special base class: |
| 209 | |
| 210 | <PRE> |
| 211 | BaseClass1 = MetaClass1("BaseClass1", (), {}) |
| 212 | </PRE> |
| 213 | |
| 214 | We can now use BaseClass1 as a base class in a class statement: |
| 215 | |
| 216 | <PRE> |
| 217 | class MySpecialClass(BaseClass1): |
| 218 | i = 1 |
| 219 | def f(s): pass |
| 220 | </PRE> |
| 221 | |
| 222 | At this point, MySpecialClass is defined; it is a metainstance of |
| 223 | MetaClass1 just like BaseClass1, and in fact the expression |
| 224 | ``BaseClass1.__class__ == MySpecialClass.__class__ == MetaClass1'' |
| 225 | yields true. |
| 226 | |
| 227 | <P>We are now ready to create instances of MySpecialClass. Let's |
| 228 | assume that no constructor arguments are required: |
| 229 | |
| 230 | <PRE> |
| 231 | x = MySpecialClass() |
| 232 | y = Myspecialclass() |
| 233 | print x.__class__, y.__class__ |
| 234 | </PRE> |
| 235 | |
| 236 | The print statement shows that x and y are instances of HelperClass1. |
| 237 | How did this happen? MySpecialClass is an instance of MetaClass1 |
| 238 | (``meta'' is irrelevant here); when an instance is called, its |
| 239 | __call__ method is invoked, and presumably the __call__ method defined |
| 240 | by MetaClass1 returns an instance of HelperClass1. |
| 241 | |
| 242 | <P>Now let's see how we could use metaprogramming -- what can we do |
| 243 | with metaclasses that we can't easily do without them? Here's one |
| 244 | idea: a metaclass could automatically insert trace calls for all |
| 245 | method calls. Let's first develop a simplified example, without |
| 246 | support for inheritance or other ``advanced'' Python features (we'll |
| 247 | add those later). |
| 248 | |
| 249 | <PRE> |
| 250 | import types |
| 251 | |
| 252 | class Tracing: |
| 253 | def __init__(self, name, bases, namespace): |
| 254 | """Create a new class.""" |
| 255 | self.__name__ = name |
| 256 | self.__bases__ = bases |
| 257 | self.__namespace__ = namespace |
| 258 | def __call__(self): |
| 259 | """Create a new instance.""" |
| 260 | return Instance(self) |
| 261 | |
| 262 | class Instance: |
| 263 | def __init__(self, klass): |
| 264 | self.__klass__ = klass |
| 265 | def __getattr__(self, name): |
| 266 | try: |
| 267 | value = self.__klass__.__namespace__[name] |
| 268 | except KeyError: |
| 269 | raise AttributeError, name |
Guido van Rossum | 0cdb887 | 1997-08-26 00:08:51 +0000 | [diff] [blame^] | 270 | if type(value) is not types.FunctionType: |
Guido van Rossum | 1fb071c | 1997-08-25 21:36:44 +0000 | [diff] [blame] | 271 | return value |
| 272 | return BoundMethod(value, self) |
| 273 | |
| 274 | class BoundMethod: |
| 275 | def __init__(self, function, instance): |
| 276 | self.function = function |
| 277 | self.instance = instance |
| 278 | def __call__(self, *args): |
Guido van Rossum | 0cdb887 | 1997-08-26 00:08:51 +0000 | [diff] [blame^] | 279 | print "calling", self.function, "for", self.instance, "with", args |
Guido van Rossum | 1fb071c | 1997-08-25 21:36:44 +0000 | [diff] [blame] | 280 | return apply(self.function, (self.instance,) + args) |
Guido van Rossum | 0cdb887 | 1997-08-26 00:08:51 +0000 | [diff] [blame^] | 281 | |
| 282 | Trace = Tracing('Trace', (), {}) |
| 283 | |
| 284 | class MyTracedClass(Trace): |
| 285 | def method1(self, a): |
| 286 | self.a = a |
| 287 | def method2(self): |
| 288 | return self.a |
| 289 | |
| 290 | aninstance = MyTracedClass() |
| 291 | |
| 292 | aninstance.method1(10) |
| 293 | |
| 294 | print "the answer is %d" % aninstance.method2() |
| 295 | </PRE> |
| 296 | |
| 297 | Confused already? The intention is to read this from top down. The |
| 298 | Tracing class is the metaclass we're defining. Its structure is |
| 299 | really simple. |
| 300 | |
| 301 | <P> |
| 302 | |
| 303 | <UL> |
| 304 | |
| 305 | <LI>The __init__ method is invoked when a new Tracing instance is |
| 306 | created, e.g. the definition of class MyTracedClass later in the |
| 307 | example. It simply saves the class name, base classes and namespace |
| 308 | as instance variables.<P> |
| 309 | |
| 310 | <LI>The __call__ method is invoked when a Tracing instance is called, |
| 311 | e.g. the creation of aninstance later in the example. It returns an |
| 312 | instance of the class Instance, which is defined next.<P> |
| 313 | |
| 314 | </UL> |
| 315 | |
| 316 | <P>The class Instance is the class used for all instances of classes |
| 317 | built using the Tracing metaclass, e.g. aninstance. It has two |
| 318 | methods: |
| 319 | |
| 320 | <P> |
| 321 | |
| 322 | <UL> |
| 323 | |
| 324 | <LI>The __init__ method is invoked from the Tracing.__call__ method |
| 325 | above to initialize a new instance. It saves the class reference as |
| 326 | an instance variable. It uses a funny name because the user's |
| 327 | instance variables (e.g. self.a later in the example) live in the same |
| 328 | namespace.<P> |
| 329 | |
| 330 | <LI>The __getattr__ method is invoked whenever the user code |
| 331 | references an attribute of the instance that is not an instance |
| 332 | variable (nor a class variable; but except for __init__ and |
| 333 | __getattr__ there are no class variables). It will be called, for |
| 334 | example, when aninstance.method1 is referenced in the example, with |
| 335 | self set to aninstance and name set to the string "method1".<P> |
| 336 | |
| 337 | </UL> |
| 338 | |
| 339 | <P>The __getattr__ method looks the name up in the __namespace__ |
| 340 | dictionary. If it isn't found, it raises an AttributeError exception. |
| 341 | (In a more realistic example, it would first have to look through the |
| 342 | base classes as well.) If it is found, there are two possibilities: |
| 343 | it's either a function or it isn't. If it's not a function, it is |
| 344 | assumed to be a class variable, and its value is returned. If it's a |
| 345 | function, we have to ``wrap'' it in instance of yet another helper |
| 346 | class, BoundMethod. |
| 347 | |
| 348 | <P>The BoundMethod class is needed to implement a familiar feature: |
| 349 | when a method is defined, it has an initial argument, self, which is |
| 350 | automatically bound to the relevant instance when it is called. For |
| 351 | example, aninstance.method1(10) is equivalent to method1(aninstance, |
| 352 | 10). In the example if this call, first a temporary BoundMethod |
| 353 | instance is created with the following constructor call: temp = |
| 354 | BoundMethod(method1, aninstance); then this instance is called as |
| 355 | temp(10). After the call, the temporary instance is discarded. |
| 356 | |
| 357 | <P> |
| 358 | |
| 359 | <UL> |
| 360 | |
| 361 | <LI>The __init__ method is invoked for the constructor call |
| 362 | BoundMethod(method1, aninstance). It simply saves away its |
| 363 | arguments.<P> |
| 364 | |
| 365 | <LI>The __call__ method is invoked when the bound method instance is |
| 366 | called, as in temp(10). It needs to call method1(aninstance, 10). |
| 367 | However, even though self.function is now method1 and self.instance is |
| 368 | aninstance, it can't call self.function(self.instance, args) directly, |
| 369 | because it should work regardless of the number of arguments passed. |
| 370 | (For simplicity, support for keyword arguments has been omitted.)<P> |
| 371 | |
| 372 | </UL> |
| 373 | |
| 374 | <P>In order to be able to support arbitrary argument lists, the |
| 375 | __call__ method first constructs a new argument tuple. Conveniently, |
| 376 | because of the notation *args in __call__'s own argument list, the |
| 377 | arguments to __call__ (except for self) are placed in the tuple args. |
| 378 | To construct the desired argument list, we concatenate a singleton |
| 379 | tuple containing the instance with the args tuple: (self.instance,) + |
| 380 | args. (Note the trailing comma used to construct the singleton |
| 381 | tuple.) In our example, the resulting argument tuple is (aninstance, |
| 382 | 10). |
| 383 | |
| 384 | <P>The intrinsic function apply() takes a function and an argument |
| 385 | tuple and calls the function for it. In our example, we are calling |
| 386 | apply(method1, (aninstance, 10)) which is equivalent to calling |
| 387 | method(aninstance, 10). |
| 388 | |
| 389 | <P>From here on, things should come together quite easily. The output |
| 390 | of the example code is something like this: |
| 391 | |
| 392 | <PRE> |
| 393 | calling <function method1 at ae8d8> for <Instance instance at 95ab0> with (10,) |
| 394 | calling <function method2 at ae900> for <Instance instance at 95ab0> with () |
| 395 | the answer is 10 |
| 396 | </PRE> |
| 397 | |
| 398 | <P>That was about the shortest meaningful example that I could come up |
| 399 | with. A real tracing metaclass (for example, <A |
| 400 | HREF="#Trace">Trace.py</A> discussed below) needs to be more |
| 401 | complicated in two dimensions. |
| 402 | |
| 403 | <P>First, it needs to support more advanced Python features such as |
| 404 | class variables, inheritance, __init__ methods, and keyword arguments. |
| 405 | |
| 406 | <P>Second, it needs to provide a more flexible way to handle the |
| 407 | actual tracing information; perhaps it should be possible to write |
| 408 | your own tracing function that gets called, perhaps it should be |
| 409 | possible to enable and disable tracing on a per-class or per-instance |
| 410 | basis, and perhaps a filter so that only interesting calls are traced; |
| 411 | it should also be able to trace the return value of the call (or the |
| 412 | exception it raised if an error occurs). Even the Trace.py example |
| 413 | doesn't support all these features yet. |
| 414 | |
| 415 | <P> |
| 416 | |
Guido van Rossum | 1fb071c | 1997-08-25 21:36:44 +0000 | [diff] [blame] | 417 | <HR> |
| 418 | |
Guido van Rossum | 0cdb887 | 1997-08-26 00:08:51 +0000 | [diff] [blame^] | 419 | <H1>Real-life Examples</H1> |
Guido van Rossum | 1fb071c | 1997-08-25 21:36:44 +0000 | [diff] [blame] | 420 | |
Guido van Rossum | 0cdb887 | 1997-08-26 00:08:51 +0000 | [diff] [blame^] | 421 | <P>Have a look at some very preliminary examples that I coded up to |
| 422 | teach myself how to use metaprogramming: |
Guido van Rossum | 1fb071c | 1997-08-25 21:36:44 +0000 | [diff] [blame] | 423 | |
| 424 | <DL> |
| 425 | |
| 426 | <DT><A HREF="Enum.py">Enum.py</A> |
| 427 | |
| 428 | <DD>This (ab)uses the class syntax as an elegant way to define |
| 429 | enumerated types. The resulting classes are never instantiated -- |
| 430 | rather, their class attributes are the enumerated values. For |
| 431 | example: |
| 432 | |
| 433 | <PRE> |
| 434 | class Color(Enum): |
| 435 | red = 1 |
| 436 | green = 2 |
| 437 | blue = 3 |
| 438 | print Color.red |
| 439 | </PRE> |
| 440 | |
| 441 | will print the string ``Color.red'', while ``Color.red==1'' is true, |
| 442 | and ``Color.red + 1'' raise a TypeError exception. |
| 443 | |
| 444 | <P> |
| 445 | |
Guido van Rossum | 0cdb887 | 1997-08-26 00:08:51 +0000 | [diff] [blame^] | 446 | <DT><A NAME=Trace></A><A HREF="Trace.py">Trace.py</A> |
Guido van Rossum | 1fb071c | 1997-08-25 21:36:44 +0000 | [diff] [blame] | 447 | |
Guido van Rossum | 0cdb887 | 1997-08-26 00:08:51 +0000 | [diff] [blame^] | 448 | <DD>The resulting classes work much like standard |
| 449 | classes, but by setting a special class or instance attribute |
| 450 | __trace_output__ to point to a file, all calls to the class's methods |
| 451 | are traced. It was a bit of a struggle to get this right. This |
| 452 | should probably redone using the generic metaclass below. |
Guido van Rossum | 1fb071c | 1997-08-25 21:36:44 +0000 | [diff] [blame] | 453 | |
| 454 | <P> |
| 455 | |
| 456 | <DT><A HREF="Meta.py">Meta.py</A> |
| 457 | |
| 458 | <DD>A generic metaclass. This is an attempt at finding out how much |
| 459 | standard class behavior can be mimicked by a metaclass. The |
| 460 | preliminary answer appears to be that everything's fine as long as the |
| 461 | class (or its clients) don't look at the instance's __class__ |
| 462 | attribute, nor at the class's __dict__ attribute. The use of |
| 463 | __getattr__ internally makes the classic implementation of __getattr__ |
| 464 | hooks tough; we provide a similar hook _getattr_ instead. |
| 465 | (__setattr__ and __delattr__ are not affected.) |
| 466 | (XXX Hm. Could detect presence of __getattr__ and rename it.) |
| 467 | |
| 468 | <P> |
| 469 | |
| 470 | <DT><A HREF="Eiffel.py">Eiffel.py</A> |
Guido van Rossum | 0cdb887 | 1997-08-26 00:08:51 +0000 | [diff] [blame^] | 471 | ppp |
Guido van Rossum | 1fb071c | 1997-08-25 21:36:44 +0000 | [diff] [blame] | 472 | <DD>Uses the above generic metaclass to implement Eiffel style |
| 473 | pre-conditions and post-conditions. |
| 474 | |
| 475 | <P> |
Guido van Rossum | 0cdb887 | 1997-08-26 00:08:51 +0000 | [diff] [blame^] | 476 | |
| 477 | <DT><A HREF="Synch.py">Synch.py</A> |
| 478 | |
| 479 | <DD>Uses the above generic metaclass to implement synchronized |
| 480 | methods. |
| 481 | |
| 482 | <P> |
| 483 | |
Guido van Rossum | 1fb071c | 1997-08-25 21:36:44 +0000 | [diff] [blame] | 484 | </DL> |
| 485 | |
Guido van Rossum | 0cdb887 | 1997-08-26 00:08:51 +0000 | [diff] [blame^] | 486 | <P>A pattern seems to be emerging: almost all these uses of |
| 487 | metaclasses (except for Enum, which is probably more cute than useful) |
| 488 | mostly work by placing wrappers around method calls. An obvious |
| 489 | problem with that is that it's not easy to combine the features of |
| 490 | different metaclasses, while this would actually be quite useful: for |
| 491 | example, I wouldn't mind getting a trace from the test run of the |
| 492 | Synch module, and it would be interesting to add preconditions to it |
| 493 | as well. This needs more research. Perhaps a metaclass could be |
| 494 | provided that allows stackable wrappers... |
| 495 | |
Guido van Rossum | 1fb071c | 1997-08-25 21:36:44 +0000 | [diff] [blame] | 496 | </BODY> |
| 497 | |
| 498 | </HTML> |