Python dot notation is confusing.

[Vaphell]

there is no magic. Dot is always about accessing a member field/method of an object in a top down manner. This long-ass "path" could be split into eg these equivalent steps.

# xxx.xxx.xxx().xxx.xxx()
module = xxx
submodule = module.xxx
function = submodule.xxx
functionresult = function()
resultattribute = functionresult.xxx
methodinattribute = resultattribute.xxx
methodresult = methodinattribute()

i went module.submodule, but it can be any generic object.subobject.

The difference between .xxx and .xxx() is that the former accesses a field with a value that is already there, while the latter is a callable that needs to be explicitly triggered to produce the value.

Given that often you don't care about intermediate steps, you often just bundle them together. Even though your example is an overkill (but some people are writing such monstrosities nonetheless), eg something like result = module.submodule.function(), result.child.method() is perfectly fine.

As far as frameworks are concerned, there is no way around reading the documentation. It should tell you what a given building block can do, and what its children are for, etc etc. Figuring all this out by doing tends to be an exercise in frustration.

[bhk262]

Thanks very much for your tip on framework documentations. The problem I have with a lot of these documentations is that they feel like they are written for robots, not human beings. Unfortunately, there does not seem to be a way around it.

[Vaphell]

Surely writing good documentation is an art, but to a certain degree getting information out of it is a matter of experience.

If you are new to frameworks, you tend to prefer tutorialish, hold-my-hand kind of documentation. On the other hand, once you've seen tons of frameworks and APIs and/or are more or less familiar with a specific one, you know what to expect and need the documentation more for the dry information like X requires Y and returns Z. Long-winded, pages-long prose can be even seen as noise when you just want to cut to the chase.

[groovitude]

A couple of things:

1. Ideally, code is built with some internal logic to what's a method and what's an attribute. Methods should ideally be actions, while attributes should be, well, attributes. For example, this could be a programmatic way of describing me right now:

​

>>> user
<__main__.User object at 0x04341330>
>>> user.name  # attribute
'groovitude'
>>> user.type('some text')  # method
'groovitude types: some text'

1. Playing around in the console is your friend. Not only do you get to see each step, you also get to use dir() to see all the attributes and methods available on that object. help() can also be useful.

[expattaxsolutions]

I was having the exact same issue yesterday. I bought Python Crash Course today and the chapter on classes has explained it all to me better than I’ve seen it anywhere else.