On 2005 Feb 20, at 04:35, Jack Diederich wrote:
I always use new style classes so I only have to remember one set of behaviors.
I agree: that's reason #1 I recommend always using new-style whenever I teach / tutor / mentor in Python nowadays.
"__metaclass__ = type" is warty, it has the "action at a distance" problem that
decorators solve for functions.
I disagree. I view it as akin to a "from __future__ import" except that -- since the compiler doesn't need-to-know, as typeclass-picking happens at runtime -- it was accomplished by less magical and more flexible means.
I didn't dig into the C but does having 'type'
as metaclass guarantee the same behavior as inheriting 'object' or does object
provide something type doesn't? *wince*
I believe the former holds, since for example:
>>> class X: __metaclass__ = type ... >>> X.__bases__ (<type 'object'>,)
If you're making a newstyle class with an oldstyle base, it's different:
>>> class Y: pass
...
>>> class X(Y): __metaclass__ = type
...
Traceback (most recent call last):
File "<stdin>", line 1, in ?
TypeError: Error when calling the metaclass bases
a new-style class can't have only classic basesin this case, you do need to inherit object explicitly:
>>> class X(Y, object): pass ... >>> X.__bases__ (<class __main__.Y at 0x38d330>, <type 'object'>) >>> type(X) <type 'type'>
This is because types.ClassType turns somersaults to enable this: in this latter construct, Python's mechanisms determine ClassType as the metaclass (it's the metaclass of the first base class), but then ClassType in turn sniffs around for another metaclass to delegate to, among the supplied bases, and having found one washes its hands of the whole business;-).
Alex
_______________________________________________ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
