Python Conventions – Why Are Methods Considered Class Attributes?

conventionsobject-orientedpython

I read in a book that both methods and fields are considered the attributes of a class in Python. However, recently I was told by a friend of mine that methods may not be considered the attributes of a class.

Then I decided to check this out again, and found this question mentioned on Wikipedia saying that this is a Python "tradition" to refer to methods as attributes, in contrast to other object-oriented programming languages.

So my question is: why are methods considered the class atributes along with the fields in Python in contrast to other languages?

Thank you!

Best Answer

Your friend was wrong. Methods are attributes.

Everything in Python is objects, really, with methods and functions and anything with a __call__() method being callable objects. They are all objects that respond to the () call expression syntax.

Attributes then, are objects found by attribute lookup on other objects. It doesn't matter to the attribute lookup mechanism that what is being looked up is a callable object or not.

You can observe this behaviour by looking up just the method, and not calling it:

>>> class Foo(object):
...     def bar(self):
...         pass
... 
>>> f = Foo()
>>> f.bar
<bound method Foo.bar of <__main__.Foo object at 0x1023f5590>>

Here f.bar is an attribute lookup expression, the result is a method object.

Of course, your friend me be a little bit right too; what is really happening is that methods are special objects that wrap functions, keeping references to the underlying instance and original function, and are created on the fly by accessing the function as an attribute. But that may be complicating matters a little when you first start out trying to understand Python objects. If you are interested in how all that works, read the Python Descriptor HOWTO to see how attributes with special methods are treated differently on certain types of attribute access.

This all works because Python is a dynamic language; no type declarations are required. As far as the language is concerned, it doesn't matter if Foo.bar is a string, a dictionary, a generator, or a method. This is in contrast to compiled languages, where data is very separate from methods, and each field on an instance needs to be pinned down to a specific type beforehand. Methods generally are not objects, thus a separate concept from data.

Related Solutions

Object-oriented – Should main method be only consists of object creations and method calls

The point your friend is making is that an application should merely be bootstrapped by the main method, and nothing more. By having the main method in its own class, you are simply reinforcing that fact by keeping it independent of any application logic. The role of the main method would be to parse any inputs and to initialize the application with those, and possibly other, inputs.

public static void main(String[] args){
    new Foo().start(args[0]);
}

The idea is that you don't need the main method in order to initialize Foo. This allows you to easily initialize and start Foo in another context, potentially with different semantics.

public Foo initSomewhereElse(String arg){
    Foo f = new Foo();
    f.start(arg);
    return f;
}

Python Code Quality – Is It Pythonic to Have Multiple Classes in One File?

It's fine. It's fine in C++ as well, for reference.

Keeping tightly-coupled things together is sensible practice. Avoiding inappropriate coupling is also good practice. Striking the right balance isn't a matter of strict rules, but of, well, striking a balance between different concerns.

Some rules of thumb:

Size

Excessively large files can be ugly, but that's hardly the case here. Ugliness is probably a good enough reason to split a file, but developing that aesthetic sense is largely a matter of experience, so it doesn't help you figure out what to do a priori
Separation of Concerns

If your concrete implementations have very different internal concerns, your single file accumulates all those concerns. For example, implementations with non-overlapping dependencies make your single file depend on the union of all those dependencies.

So, it might sometimes be reasonable to consider the sub-classes' coupling to their dependencies outweighs their coupling to the interface (or conversely, the concern of implementing an interface is weaker than the concerns internal to that implementation).

As a specific example, take a generic database interface. Concrete implementations using an in-memory DB, an SQL RDBMS and a web query respectively may have nothing in common apart from the interface, and forcing everyone who wants the lightweight in-memory version to also import an SQL library is nasty.
Encapsulation

Although you can write well-encapsulated classes in the same module, it could encourage unnecessary coupling just because you have access to implementation details that wouldn't otherwise be exported outside the module.

This is just poor style I think, but you could enforce better discipline by splitting the module if you really can't break the habit.

Best Answer

Related Solutions

Object-oriented – Should main method be only consists of object creations and method calls

Python Code Quality – Is It Pythonic to Have Multiple Classes in One File?

Related Topic