A further thought: It is interesting that, in Python, tab-complete, method chaining, and (to some extent) conceptual order have played a role in guiding which functions people create as methods and which are created as standalone functions, with the result that typically these lists are short, easy-to-parse, and have exactly the sort of functionality that you’d expect to find.
Grammar is the most interesting: for the sort of things where you think of the action first and then the object, these are represented as standalone functions. These generally apply to actions which can be applied to many different objects (from the standard lib, things like len, zip, from an example third-party module np.save). These are all instances where I think of the action first, and are somewhat canonically named, so they are easy to find.
On the other extreme, object methods are predominantly things where I think of the object first and then the action. The A.nodes() scenario, where A is a graph, is a good example of this. In this instance, I naturally think of the graph object first, and wanting to get the nodes out of it.
Of course nothing prohibits both, as in numpy where most methods have identical standalone functions (eg. a.min() or np.min(a)), however I would argue numpy is potentially an example where making some choices about which functions are better as standalone and which are better as methods would be useful.
The two approaches I think which would mitigate some of these issues are:
- Uniform Function Call Syntax
- Methods on Objects
The first is just syntactic sugar so that A.funcname() parses to funcname(A). The second could honestly just be a list of methods for the purpose of populating a tab-complete list. Then, if A has a method list, tab-complete could pull just from that list while shift-tab-complete could return a more complete list a-la methodswith.