This is kind of a long answer, but I think it gets to the root of the real problem - scope. Just hang there while I scroll through it!
Simply importing a module does not have to give the application developer access to all its classes or methods; if I cannot SEE the source code of the module, how do I know what is available? Someone (or some THING) should tell me what I can do and explain how to use the functions that I am allowed to use, otherwise all this is useless to me.
Those who develop higher-level abstractions based on fundamental classes and methods using imported modules are represented by the DOCUMENT specification - NOT the actual source code.
The module specification describes all the functions that should be visible to the client developer. When working with large projects and software projects, the actual implementation of the module should ALWAYS remain hidden from those who use it - this is a black box with an interface to the outside world. For OOD purists, I think techie terms are “decoupling” and “cohesion.” The user of the module should know only the interface methods, not burdening with implementation details.
A module should NEVER be changed without first changing its underlying specification document, which may require review / approval by some organizations before changing the code.
As a hobby programmer (now retired), I launched a new module in which the specified document is actually written out as a giant block of comments at the top of the module, this will be the part that the user really sees in the specification library. Since it's just me, I haven't created a library yet, but that would be easy enough to do.
Then I start coding, writing down various classes and methods, but without functional bodies - just zero print statements such as "print ()" - enough for the module to compile without syntax errors. When this step is complete, I compile the completed null module - this is my specification. If I were working on a project team, I would present this specification / interface for review and comments before proceeding with body phishing.
I form the bodies of each method one at a time and compile accordingly, ensuring that syntax errors are fixed immediately on the fly. This is also a good time to start recording the temporary “main” stage of execution below to test each method as it is encoded. When coding / testing is complete, the entire test code is commented out until it is needed if updates become necessary.
In a real development team, a comment comment block will also appear in the document management library, but that's another story. The fact is that you, as a module client, see only this specification and NOT the source code.
PS: long before the start of work, I worked in the defense aerospace community, and we did pretty cool things, but things like patented algorithms and control logic of sensitive systems were hard-coded and encrypted in super-duper protected software libraries. We had access to the module / package interfaces, but not to the black box implementation areas. There was a document management tool that processed all projections at the system level, software specifications, source code, and test records — everything was synchronized together. The government had strict requirements for software quality assurance standards. Does anyone remember a language called Ada? That's how old I am!