[Python-Dev] Re: PEP 318: Can't we all just get along? (original) (raw)

Bob Ippolito bob at redivi.com
Thu Aug 19 21:38:24 CEST 2004

On Aug 19, 2004, at 3:30 PM, Paul Morrow wrote:

James Y Knight wrote:

On Aug 19, 2004, at 7:45 AM, Paul Morrow wrote: The vast majority of instance methods I've seen all use 'self' as the first parameter. Likewise, most class methods use 'cls' or 'klass' as their first parameter. If we exploit these conventions, we end up with a simple, clear, obvious mechanism for denoting (this aspect of) a method's type.

class Foo(Object): def m1(self, a, b): # this is an instance method of Foo pass def m2(cls, a, b): # this is a class method of Foo pass def m3(a, b): # this is a static method of Foo pass A special Object (capital 'O') class could work this magic so that old code didn't break. I know that this is odd. But then so are most of the great things about Python. You can do that today. See also http://www.python.org/pycon/dc2004/papers/48/conveniencytypes.py Aha! Thanks!

Whatever happened to explicit is better than implicit? ;)

However, note that IMO it is quite rude to use a metaclass (or your capital O object -- same thing) to do this, as it will break any objects inheriting from your class that don't expect the strange automatic behavior. This auto-class/staticmethod-ification should be local to your code, and thus is really a candidate for a class decorator. @automethods class Foo(object): ... But then wouldn't subclasses of Foo have the same rude behavior? In fact, isn't the use of any metaclass rude, by your definition, as it will change the default class behavior in some way?

No, a decorator happens once. A metaclass can/does have permanent effects and becomes an integral and/or annoying part of the inheritance graph.

class Foo(object): metaclass = Bar ...

is much different than

class Foo(object): ... Foo = barEquivalentFunction(Foo)

which is the same as

@barEquivalentFunction class Foo(object): ...

-bob

More information about the Python-Dev mailing list