Friday Finking: Source code organisation

[Richard Damon]

On 12/28/19 5:35 PM, DL Neil via Python-list wrote:
> Is it helpful to, and thus, do you have a style/convention for 
> ordering the methods within each class in your code?
>
>
> Python's "honking great idea" of namespaces enables us to gather 
> functions/methods under a single name-umbrella, thereby avoiding 
> name-clashes/name-space 'pollution'. [Oh yeah!]
>
> Thus, if we collect a bunch of module-functions, we refer to them 
> collectively by module-name/import-name, eg
>
>     import collected_functions_module as cfm
>     ...
>     cfm.make_it_happen()
>     cfm.make_it_better()
>
> Similarly, methods within a class may be accessed either as 
> class-methods, or through instances (as required).
> [am assuming no code example necessary]
>
> A major difference however, is that if our mythical collection of 
> module-functions has an internal-reference, eg b() requires a(), then 
> function a() MUST exist, ie be defined, 'before' function b(). Whereas 
> a class's methods may be defined in any (complete) sequence. 

If module function b calls function a in the same module, then a has to 
exist when b is CALLED, not before it is defined. Thus it is very 
possible to get a multi-function recursion where b() calls a() which 
then calls b(). (The existence of items mentioned within a function are 
looked up until that statement as actually executed)

as an example, in a module:

def b():

   a()

def a():

   pass

is perfectly valid.

Modules are a bit different, if module b needs resources from module a, 
it needs to import module a before it can use them. If module a also 
needs resources from module b, and imports it, then stuff from b might 
not be available while doing the running of module a that is defining 
the items in a.

-- 
Richard Damon