Terminology

Mental model:

• A variable stored in an instance or class is called an attribute.
• A function stored in an instance or class is called a method.

According to Python's glossary:

attribute: A value associated with an object which is referenced by name using dotted expressions. For example, if an object o has an attribute a it would be referenced as o.a

method: A function which is defined inside a class body. If called as an attribute of an instance of that class, the method will get the instance object as its first argument (which is usually called self). See function and nested scope.

Examples

Terminology applied to actual code:

a = 10                          # variable

def f(b):                       # function  
    return b ** 2

class C:

    c = 20                      # class attribute

    def __init__(self, d):      # "dunder" method
        self.d = d              # instance attribute

    def show(self):             # method
        print(self.c, self.d) 

e = C(30)
e.g = 40                        # another instance attribute

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.

An attribute is a variable that is looked up on another object using dot syntax: obj.attribute. The way Python is designed, attribute lookups can do a variety of things, and that variety can sometimes lead to bugs if you don't really understand what is happening (this is what the documentation you linked to warns about).

The most basic issue is that an attribute lookup can find either a value stored in the object's instance dictionary, or it can find something from the object's class (or a base class, if there's inheritance going on). Methods are functions stored in the class, but you usually use them by looking them up on an instance (which "binds" the method, inserting the object as the first arguemnt when the method is called).

The exact sequence of what is checked when is a bit complicated (I described the full process in an answer to another question), but at the most basic level, instance attributes usually take precedence over class attribute.

If an instance attribute and a class attribute with the same name both exist, usually only the instance attribute will be accessible. This can be very confusing if it is unintended.

Consider the following code:

class Foo(object):
    def __init__(self, lst):
        self.lst = lst

    def sum(self):
        self.sum = sum(self.lst)
        return self.sum

f = Foo([1,2,3])

print(f.sum())
print(f.sum())

At the bottom of this code, we make two identical calls. The first works just fine, but the second will raise an exception.

This is because the first time we look up f.sum we find a method in the Foo class. We can call the method with no problems. The trouble comes from the fact that the sum method assigns the result of its calculation (the sum of the elements in self.lst) to an instance attribute also named sum. This hides the sum method from view.

When second f.sum() call looks up f.sum, it finds the instance attribute, containing the integer 6, rather than the expected method. An integer is not callable, so we get an exception.

The solution, of course, is not to use the same name for the method and attribute. The code above is a pretty trivial example. The bugs caused by this sort of thing in more complex code can be much more difficult to figure out.

If you're writing code that adds attributes to objects you don't know much about, you should be careful to avoid common names. If you're writing a mixin class, consider using two leading underscores in the attribute names to trigger Python's name mangling, which is designed for exactly this sort of situation.

Addendum: It's also possible that the distinction the documentation is trying to make is between data and non-data descriptors. Methods are the most common kind of non-data descriptor, so it might make a degree of sense to call them "method attributes" (especially in contrast to "data attributes" which would be the corresponding name for data descriptors), though I'm not aware of that language being used more widely. The important difference between the two kinds of descriptors is that data descriptors (like property) get processed before the instance dictionary is checked for an ordinary instance variable. As discussed above, non-data descriptors like methods get processed only after the instance dictionary is checked, so they can be shadowed by data stored on the instance.

Properly structured is subjective. :)

Generally, the more moving parts you have (i.e. mutable state), the harder it is to reason about your code. There are more pieces to fit in your mental model of the code, but there are additional concerns as well, such as ensuring the derived values stay coherent when a value is updated, or or that your code is correct if ran in a concurrent context. Therefore, I would consider leaving the calculation of the derived attributes in a method as a good default since it minimizes the state required.

Not all calculations are equal, however. It might be too computationally expensive to re-calculate the derived values every time they are needed (e.g. in a tight loop), at which time you might want to consider caching. The good thing is that if the computation is hidden in a method, caching simply becomes an implementation detail, leaving the rest of your code unaware of this optimization. If your use case warrants it, you may even use the Decorator pattern to implement this caching, decoupling the actual, interesting calculation from the technical details of caching.

More specifically for Python, you can define your derived value as a property instead of a method. You have the benefits of keeping the state to the minimum while still seemingly using an attribute (if that makes sense in your use case). That being said, a property is generally expected not to perform an expensive operation, so if that is your case, I would generally prefer to keep the method.

Methods are attributes too. They just happen to be callable objects.

You can detect if an object is callable by using the callable() function:

>>> def foo(): pass
...
>>> callable(foo)
True
>>> callable(1)
False

When you call a method, you look up the attribute (a getattr() operation) and then call the result:

c.setAttr(newvalue)

is two steps; finding the attribute (which in this case looks up the attribute on the class, and treats it as a descriptor), then calls the resulting object, a method.

When you assign to an attribute, you rebind that name to a new value:

c.setAttr = 'something else'

would be a setattr() operation.

If you wanted to intercept getting and setting attributes on instances of your class, you could provide the attribute access hooks, __getattr__, __setattr__ and __delattr__.

If you wanted to add a method to an instance, you would have to treat the function as a descriptor object, which produces a method object:

>>> class Foo: pass
... 
>>> foo = Foo()  # instance
>>> def bar(self): pass
... 
>>> bar
<function bar at 0x10b85a320>
>>> bar.__get__(foo, Foo)
<bound method Foo.bar of <__main__.Foo instance at 0x10b85b830>>

The return value of function.__get__(), when given an instance and a class, is a bound method. Calling that method will call the underlying function with self bound to the instance.

And speaking of descriptors, the property() function returns a descriptor too, making it possible to have functions that behave like attributes; they can intercept the getattr(), setattr() and delattr() operations for just that attribute and turn it into a function call:

>>> class Foo:
...     @property
...     def bar(self):
...         return "Hello World!"
... 
>>> foo = Foo()
>>> foo.bar
"Hello World!"

Accessing .bar invoked the bar property get hook, which then calls the original bar method.

In almost all situations, you are not going to need the callable() function; you document your API, and provide methods and attributes and the user of your API will figure it out without testing each and every attribute to see if it is callable. With properties, you have the flexibility of providing attributes that are really callables in any case.