[Tutor] Everything in one file?

[Mats Wichmann]

On 07/18/2018 10:00 AM, Alan Gauld via Tutor wrote:
> On 18/07/18 14:46, Shall, Sydney wrote:
> 
>>  > is no need to put every class in a separate file, and it usually leads
>>  > to complicated dependencies and circular imports.
> 
>> I have constructed a program which has a parent class and a child class 
>> and I have them in two different files. I import the parent class into 
>> the child class and create instances with the child class. This works fine.
>> But, would it be better to have both classes in one file? 
> 
> Probably if you know when writing them that you will need to
> import parent to use child and especially if you are unlikely
> to ever use parent without child(or some other child class).
> 
>> Would then the 
>> child class 'know' that the parent class is in the file?

I had been writing something here and then saw Alan and Steven had
already sent pretty much what I was trying to say!

> Python visibility is controlled by the scope rules (and some other magic
> stuff that applies to packages but needn't concern us here!)
> 
> The scope that we are concerned with is module scope,
> sometimes called global scope, but not in the normal sense
> that global has in other languages. Module or global scope
> means that everything inside a module is visible to
> everything else inside the same module.
> 
> So yes you child class can see the parent class if
> it is in the same file (aka module).

A couple of extra points...  first, in standard Python, function and
class definitions are runnable statements which are evaluated when
encountered (this sometimes surprises new developers), creating objects
which are then available to use when it comes time to call them.  So
"order matters" as Steven was saying,

class Child(Parent):
    pass

class Parent:
    pass

fails on the Child class definition because there is not yet a class
object named Parent that Child can inherit from.  In compiled languages
the compiler can figure it all out since it processes it all up front
before anything is run, but may still require "forward declarations" to
make its life simpler, so it's not so different after all.


second, Python creates namespaces - C++ developers, say, may be used to
declaring their own namespace, and being able to split those namespaces
across multiple files, but Python tends to use a module-based approach.
If you just write a single Python file, and run it, Python considers
that to be a module named __main__ (stick the line  print(__name__) in a
python file and run it to see, or use the interpreter), and that has its
own set of symbols, called globals but really just module-global.  If
you want to get the symbols from another module, you need to "import"
them, and they appear in a namespace matching that module name. So,

# assume module foo defines function bar
import foo     # makes available the symbols from foo
# your module can call foo as foo.bar()

but also:

from foo import bar   # makes available that symbol in _your_ namespace
# your module can now call bar as bar().

These are really just symbol-visibility tricks, so you can do both if
you have any desire to do so:

import foo
from foo import bar
bar()
foo.bar()

maybe that's drifting off-topic, so I'll stop now :)