CODEWITHSUNDEEP
pythonoopimport
Skitzafreak
Skitzafreak

Reputation: 1917

Python Importing with OOP

This question concerns when you should have imports for Python modules and how it all interacts when you are trying to take an OOP approach to what you're making.

Let's say we have the following Modules:

ClassA.py:

class Class_A:

    def doSomething(self):
        #doSomething

ClassB.py

class Class_B:

    def doSomethingElse(self):
        #doSomethingElse

ClassC.py

class Class_C:

    def __init__(self, ClassAobj, ClassBobj):
        self.a = ClassAobj
        self.b = ClassBobj

    def doTheThing(self):
        self.a.doSomething()
        self.b.doSomethingElse()

Main.py:

from ClassA import Class_A
from ClassB import Class_B
from ClassC import Class_C

a = Class_A()
b = Class_B()
c = Class_C(a,b)

In here Class_C uses objects of Class_A and Class_B however it does not have import statements for those classes. Do you see this creating errors down the line, or is this fine? Is it bad practice to do this?

Would having imports for Class_A and Class_B inside of Class_C cause the program as a whole to use more memory since it would be importing them for both Main.py and ClassC.py? Or will the Python compiler see that those modules have already been imported and just skip over them?

I'm just trying to figure out how Python as a language ticks with concerns to importing and using modules. Basically, if at the topmost level of your program (your Main function) if you import everything there, would import statements in other modules be redundant?

Upvotes: 2

Views: 3149

Answers (3)

RemcoGerlich
RemcoGerlich

Reputation: 31260

You don't use Class_A or Class_B directly in Class_C, so you don't need to import them there.

Extra imports don't really use extra memory, there is only a single instance of each module in memory. Import just creates a name for the module in the current module namespace.

In Python, it's not idiomatic to have a single class per file. It's normal to have closely related classes all in the same file. A module name "ClassA" looks silly, that is the name of a class, not of a module.

You can only use a module inside another one if it's imported there. For instance the sys module is probably already in memory after Python starts, as so many things use it, including import statements.

An import foo statement does two things:

  • If the foo module is not in memory yet, it is loaded, parsed, executed and then placed in sys.modules['foo'].
  • A local name foo is created that also refers to the module in sys.modules.

So if you have say a print() in your module (not inside a function), then that is only executed the first time the module is imported.

Then later statements after the import can do things with foo, like foo.somefunc() or print(foo.__name__).

Upvotes: 4

chepner
chepner

Reputation: 531345

Importing a module does two things: it executes the code stored in the module, and it adds name bindings to the module doing the importing. ClassC.py doesn't need to import ClassA or ClassB because it doesn't know or care what types the arguments to ClassC.__init__ have, as long as they behave properly when used. Any references to code needed by either object is stored in the object itself.

Upvotes: 0

Prune
Prune

Reputation: 77857

C does not need the import statements; all it uses is a pair of object handles (i.e. pointers). As long as it does not try to access any method or attribute of those objects, the pure assignment is fine. If you do need such additions, then you need the import statements.

This will not cause additional memory usage in Main: Python checks (as do most languages) packages already imported, and will not import one multiple times. Note that this sometimes means that you have to be careful of package dependencies and importation order.

Upvotes: 1

Related Questions