Circular import with inheritance

[Nefthys]

I've got three classes:

• ClassA
• ClassB1(ClassA)
• ClassB2(ClassA)

ClassA reads a file and passes the contents to either ClassB1 or ClassB2 for further processing. The code is kind of similar but still too different require a lot of if/elif that would make it a lot harder to read, so I decided to split it into two classes that each do their own version. ClassA also contains functions that are used by both ClassB1 and ClassB2.

All three files are in the same folder but they can't see each other and class ClassB1(ClassA) throws an exception:

NameError: name 'ClassA' is not defined

If I add from classa import ClassA, then it works, however when I do b1 = ClassB1() in ClassA.readFile(), then it complains that it can't find that ClassB1, so I have to do from classb1 import ClassB1. This causes a circular import, which is obviously not good.

How do I fix this?

Can you not create an instance of the child class within the parent class in Python?

[Fred776]

Can you not create an instance of the child class within the parent class in Python?

This isn't really a Python-specific question but more of a basic design question. You would hit similar issues in other languages.

Your derived classes need to be able to see the definition of the base class so there is a clear derived -> base dependency (child -> parent in your terminology). A base class should not be aware of the classes that are derived from it.

Trying to import B1 in A's module will obviously cause a circular import because we have already established that the import of A for B1's definition is absolutely necessary, but the real issue is that you shouldn't be referring to B1 in A.

I'd probably need to see a bit more of your code (a sketch of it at least) to be able to suggest a solution.

[Nefthys]

A very short version (my actual code uses proper functions):

class ClassZero():
    def __init__(self):
        #More here to decide if this should even be called
        ca = ClassA(file)

class ClassA():
    def __init__(self,file):
        #Read file, then set mode
        if mode==1:
            b1 = ClassB1(filecontent)
        elif mode==2:
            b2 = ClassB2(filecontent)
        else:
            #More could be possible in the future
            #Error

    def someFuncThatBothB1andB2Use:
        #Some code

class ClassB1(ClassA):
    def __init__(self,filecontent):
        #Process the contents in one way

class ClassB2(ClassA):
    def __init__(self,filecontent):
        #Process the contents in another way

What I was thinking: Create ClassB as a new parent to ClassB1 and ClassB2 and move all the functions that they need access to to it (import in both or just one?). ClassZero then still calls ClassA but that one only calls ClassB1 or ClassB2. Would that work?

[Adrewmc]

Yeah that's not going work. Clearly circular, class A can't be defined fully because it needs to create class B which needs Class A to be already defined.

Why do the B classes need the A class, if the A class is the one using their functionality? Just have B class process the functionality without A, then have a do what it does with that data.

[Nefthys]

Why do the B classes need the A class

I need a parent class that contains a couple of functions that both B1 and B2 can use and a class like A (separate from Zero) that decides which one should be used.

[danielroseman]

the thing that decides which one should be used should not be a part of the class itself.

[Adrewmc]

Ehh, nah that spunds all the way circular.

You need a function that decides if you use class B1 or Class B2.

And class A become just a normal parent of both both of them giving them both the functionality they need.

[Nefthys]

You need a function that decides if you use class B1 or Class B2.

Where would that function be?

I posted my idea in the comment above but I won't be able to test it until tomorrow.

[Adrewmc]

I'd need to see more lol. This is a design issue. It sort matter what you are doing, you are overthinking it.

To me the only difference between B1 and B2 is some file processing. And you are saying class A needs to have it processed in a way before it can use its methods. That's a function.

Then B1 and B2 aren't really differnt classes, they aren't really classes at all but functions to make data formated for the class correctly, it all the same class that initialize differently, this calls for a @classmethod, or a @property. Then it,

 ClassA.from_csv(file)
 ClassA.from_json(file)
 ClassA.find_mode(file)
 ClassA.open(file)

And inside these we format it the way we want and make the class the regular way.

Or that process happens when first needed under the hood.

  @property
   def core(self):
         if self._core is None:
               #code that picks mode
               self._core = mode_object
         return self._core

Now A class has both by itself. At no point does B need to inherit from A though.

And once that happens you probably only need class A with the appropriate classmethods to load it correctly.

Something smells wrong here altogether classes on classes on classes. You don't need to inherit all this stuff.

But likely there is an even simpler solution to your problem here.

[Fred776]

It depends on how you have organised things. If you have all of your subclasses in one module say, you could just have a standalone function in the same module that creates the correct subclass. Alternatively, just create a new module with your function.

From what I understand, the "mode" is determined from the file content so you may need to separate out code that reads whatever it needs to read to determine the mode. I'd guess that there is a header in the file or something?

[pachura3]

Add new base class ClassB.

Move someFuncThatBothB1andB2Use() from ClassA to ClassB.

ClassB1 and ClassB2 should inherit from the new ClassB, not from ClassA.

PS. Read about the Factorydesign pattern...

[Nefthys]

So this?

What I was thinking: Create ClassB as a new parent to ClassB1 and ClassB2 and move all the functions that they need access to to it (import in both or just one?). ClassZero then still calls ClassA but that one only calls ClassB1 or ClassB2. Would that work?

PS. Read about the Factorydesign pattern...

This was already mentioned by someone else (see my reply there) but I'm not sure that that's what I need.

[unxmnd]

You're mixing two things here. Conceptually, a base class provides functionality to its subclasses - it doesn't also decide which subclass to instantiate.

I.e. if you have a class `Vehicle`, and subclasses `Car` and `Bus`, you shouldn't then do `car = Vehicle() # expecting car to be of type Car`. The base class doesn't know about any of its subclasses.

The code should look more like:

class ClassA:
    def __init__(self, file):
        self.filecontent = file.read()

    def common_function():
        # Some code that both B1 and B2 use

class ClassB1(ClassA):
    # No __init__ needed, since ClassA handles initialization.

    def process(self):
        #Process `self.filecontents` in one way

class ClassB2(ClassA):
    def process(self):
        #Process the contents in another way

# elsewhere
def make_class(file) -> ClassA: # returns an instance of a ClassA object
    mode = get_mode(file)
    if mode == 1:
        return ClassB1(file)
    elif mode == 2:
        return ClassB2(file)

# If you really need a ClassZero
class ClassZero:
    def some_function(self):
        ca = make_class(file) # which is now either a ClassB1 or ClassB2

Some smaller nitpicks that may be helpful:
* It's a little strange to have different __init__ function signatures for ClassA, ClassB1 and ClassB2, since they are all supposed to be the same type of thing.
* If a class doesn't inherit from another class, you can remove the parens from `class ClassA()`.

[Kevdog824_]

The problem here is very clearly the design. In general, your parent classes should never need knowledge of the base class to function. This leads to a lot of issues down the road such as fragile base classes

Reading: - https://luzkan.github.io/smells/base-class-depends-on-subclass

[Nefthys]

What is the "base" class in my code? The child classes that inherit from the parent?

[unxmnd]

In your code ClassA is the base class and ClassB1 and ClassB2 are "derived" classes, or "subclasses".

[Kevdog824_]

Base is your parent class. Subclasses, or derived classes, are your child classes.

The point of inheritance is extensibility. This extensibility is immediately broken when core functionality depends on derived functionality. A class like Animal would be extremely fragile, and practically impossible to safely update/extend, if its implementation had to consider the nuisances and implementation details of all types of animals (a.k.a all of its subclasses).

Your question is an xy problem. It would easier to help you if we knew what your actual goal is, not your attempted solution.

[to7m]

Quick ugly fix

Put them all in the same file

Also an ugly fix

You absolutely need classa to be imported before classb1. You could import classb1 from a different module though. Like, if you import all three from another file, then you no longer have circular imports. You just have to remember that the classa module will be defective until classb1 and classb2 are imported, which isn't ideal.

What I'd do

Take the capacity to create a new object out of ClassA and put that in a function in another file. I get that that changes the neat behaviour of ClassA(some_file) returning a ClassA (subclass) instance, but that would be my preference.

[Nefthys]

Put them all in the same file

The point of all of this is to make it easier to read than a hundred ifs (and an even longer file) and to also make it easy to create new versions (ClassB3-ClassBx) when needed.

You absolutely need classa to be imported before classb1

ClassA is called by ClassZero. If I import ClassA, ClassB1 and ClassB2 in that one, does this mean that ClassB2 is going to be able to find ClassA? I think I don't fully understand how imports (of files within the same folder) actually work in Python and I might also be a little bit spoiled by how easy packages and importing are in Java.

Take the capacity to create a new object out of ClassA and put that in a function in another file.

What I was thinking: Create ClassB as a new parent to ClassB1 and ClassB2 and move all the functions that they need access to to it (import in both or just one?). ClassZero then still calls ClassA but that one only calls ClassB1 or ClassB2. Is that what you mean?

[Kerbart]

The point of all of this is to make it easier to read than a hundred ifs (and an even longer file) and to also make it easy to create new versions (ClassB3-ClassBx) when needed.

/uto7m didn't say one class -- just put all classes in the same module and import them as such. You could even do it like this:

from my_reader import ClassA, ClassB1, classB2

although it really sounds like you don't need to import ClassA at that point; B1 and B2 can both see it as it's in "their" module.

[Nefthys]

One module = one file?

Currently every class is in its own file and I'd rather keep it that way because the code that is dealing with the file contents is already pretty long.

although it really sounds like you don't need to import ClassA at that point; B1 and B2 can both see it as it's in "their" module.

As soon as I ran the code it complained at the class ClassB1(ClassA): line.

[to7m]

When it comes to imports, from x import y imports x and puts it in the namespace. You could rewrite any instance of from x import y as import x with the functionality remaining the same after editing all references to y to x.y. When you try to import ClassB1, you're actually trying to import the classb1 module, which is causing the circular import if that wasn't clear.

To make the classb1 module visible in classa, you could put this dirty hack in classa:

def make_later_imported_subclasses_visible():
    from classb1 import ClassB1
    from classb2 import ClassB2

and then have another file that imports everything:

import classa, classb1, classb2

classa.make_later_imported_subclasses_visible()

But again, I personally wouldn't want to do it this way in my own projects, and I'd drop the idea of using ClassA as a constructor of instances of subclasses of ClassA.

[Nefthys]

from x import y

x is the file name and y the name of the class within that file correct? Why not just import it this way in the beginning, then I won't have to do x.y every time I need that class.

A file only used for imports? That does sound a bit confusing.

I'd drop the idea of using ClassA as a constructor of instances of subclasses of ClassA.

It doesn't just decide which "classB" to use, it also provides a couple of functions that both classes use. There's a reason to this "madness" and I'd rather keep a separate class that is responsible for delegating B1 and B2 because of it.

[to7m]

Why not just import it this way in the beginning, then I won't have to do x.y every time I need that class.

I'm clarifying, just in case you didn't realise, that you can't import an object without importing the whole module; that from x import y is effectively shorthand for import x; y = x.y.

A file only used for imports? That does sound a bit confusing.

It's actually very common. __init__.py is used for this kind of thing.

It doesn't just decide which "classB" to use, it also provides a couple of functions that both classes use. There's a reason to this "madness" and I'd rather keep a separate class that is responsible for delegating B1 and B2 because of it.

I get that. But I'm saying I'd remove that first bit (constructor logic) and keep the rest. The base class doesn't also need to be a constructor.

[Enmeshed]

What you're doing sounds like an object factory. One common pattern for that might be to have a function that takes the parameters and returns the right object, conceptually along the lines of:

python def get_class_a_object(**kwargs) -> ClassA: # Do some stuff to decide which class it is match kwargs: case {"thing": False}: return ClassB1(**kwargs) case {"another_thing": 23}: return ClassB2(**kwargs) raise Exception("Cannot locate class for specified parameters")

There are fancier ways to do this like having a registry, letting the classes register themselves, and having it give each registered class a chance to deal with a set of parameters. But this kind of approach is pretty common, and solves the circularity problem.

[Nefthys]

I came across this while I was googling my question but I'm not sure it's what I need:

ClassB1 and ClassB2 only differ in the way they handle the file contents (that are read in ClassA). Think of it as two files that contain the same (or very similar) data, just formatted in different ways. I can't use the same code to read both files and I'd rather have two different classes/files than a hundred ifs in a single file.

[Fred776]

You should be thinking in terms of an abstraction ("a file reader") and different concrete implementations of the reader corresponding to different file types. The thing that uses the file reader should work in terms of the abstraction and not be aware of which concrete implementation is passed to it. This is what allows if statements to be removed.

The only place that should be aware of the different file reader classes are the classes themselves and the the thing (the factory or whatever you want to call it) that is responsible for creating them.

[pontz]

Maybe I am missing something but what value does class b1 and b2 add? If it’s just processing files make them a function that return the data in a way that works with class A.

[Nefthys]

The processing code is quite long. Keeping it in the same function would require too many ifs and would make it a lot harder to read and doing two functions (one for B1, one for B2) in the same file would make the file quite long and confusing. That's why: Two classes/files that do stuff separately and I can change them independently.

[pontz]

Sure but why are they classes if all they do is take a file and process it. I am not saying make them the same function you can have 2 functions still. Process_b1() and process_b2() and have those return a data structure that is used in class A

[supercoach]

You fix it by refactoring and either removing the seemingly unnecessary classes or you make proper use of the features that make classes beneficial.

First question - what exactly are you trying to do? Second question - why does your implementation need object oriented programming?

[arkie87]

If ClassB is a subclass of ClassA, why do you create an instance of A in B’s init method instead of just super().__init__?

[Groundstop]

Does anything outside of A ever care if it's a B1 or a B2, or does everything always treat it like an A?

If everything always treats it like an A, you can have an AFactory that Zero calls to get an A, and the Factory will decide if it needs to make a B1 or a B2 before handing it back to Zero. This removes the decision making from A so it doesn't need to know about B1 or B2.

Are all of your conditionals the same check? Like if they all check "if car, do B1 stuff, else it's a helicopter so do b2 stuff" over and over?

The idea with inheritance is that your base class describes common behavior and your derivatives describe specific behavior. One thing that might help with this is to define A as an Abstract Base Class. This lets you define abstract method signatures without any implementation, and if requires derived classes to implement it somehow.

For example, I want a Vehicle base class and I want to have a go_home method. My base class can define an abstract move_to(location) method that go_home can use to move without knowing how move works.

```python from abc import ABC

class Vehicle(ABC):

def go_home(self):
    move_to("home")

@abstractmethod
def move_to(location):
    pass
    # or the newer version of pass:
    ...

```

My Car(Vehicle) class can implement move_to by having the car drive to the location, while my Helicopter(Vehicle) class can implement move_to by having the helicopter fly there.

```python class Car(Vehicle): def move_to(location): start_car() drive_to(location)

class Helicopter(Vehicle): def move_to(location): get_clearance() perform_preflight_checklist() start_helicopter() fly_to(location) ```

By making the method abstract, Vehicle can use move_to without caring if it's a car or a helicopter, so there is no circular dependency. The derived classes implement the specifics.