python circular imports once again (aka what's wrong with this design)
Question: Let's consider python (3.x) scripts:

main.py:

    
    
    from test.team import team
    from test.user import user
    
    if __name__ == '__main__':
        u = user()
        t = team()
        u.setTeam(t)
        t.setLeader(u)
    

test/user.py:

    
    
    from test.team import team
    
    class user:
        def setTeam(self, t):
            if issubclass(t, team.__class__):
                self.team = t
    

test/team.py:

    
    
    from test.user import user
    
    class team:
        def setLeader(self, u):
            if issubclass(u, user.__class__):
                self.leader = u
    

Now, of course, i've got circular import and splendid ImportError.

So, not being pythonista, I have three questions. First of all:

i. How can I make this thing work ?

And, knowing that someone will inevitably say "Circular imports always
indicate a design problem", the second question comes:

ii. Why is this design bad?

And the finally, third one:

iii. What would be better alternative?

To be precise, type checking as above is only an example, there is also a
index layer based on class, which permits ie. find all users being members of
one team (user class has many subclasses, so index is doubled, for users in
general and for each specific subclass) or all teams having given user as a
member

**Edit:**

I hope that more detailed example will clarify what i try to achieve. Files
omitted for readibility (but having one 300kb source file scares me somehow,
so please assume that every class is in different file)

    
    
    # ENTITY
    
    class Entity:
        _id    = None
        _defs  = {}
        _data  = None
    
        def __init__(self, **kwargs):
            self._id   = uuid.uuid4() # for example. or randint(). or x+1.
            self._data = {}.update(kwargs)
    
        def __settattr__(self, name, value):
            if name in self._defs:
                if issubclass(value.__class__, self._defs[name]):
                    self._data[name] = value
    
                    # more stuff goes here, specially indexing dependencies, so we can 
                    # do Index(some_class, name_of_property, some.object) to find all   
                    # objects of some_class or its children where
                    # given property == some.object
    
                else:
                    raise Exception('Some misleading message')
            else:
                self.__dict__[name] = value    
    
        def __gettattr__(self, name):
            return self._data[name]
    
    # USERS 
    
    class User(Entity):
        _defs  = {'team':Team}
    
    class DPLUser(User):
        _defs  = {'team':DPLTeam}
    
    class PythonUser(DPLUser)
        pass
    
    class PerlUser(DPLUser)
        pass
    
    class FunctionalUser(User):
        _defs  = {'team':FunctionalTeam}
    
    class HaskellUser(FunctionalUser)
        pass
    
    class ErlangUser(FunctionalUser)
        pass
    
    # TEAMS
    
    class Team(Entity):
        _defs  = {'leader':User}
    
    class DPLTeam(Team):
        _defs  = {'leader':DPLUser}
    
    class FunctionalTeam(Team):
        _defs  = {'leader':FunctionalUser}
    

and now some usage:

    
    
    t1 = FunctionalTeam()
    t2 = DLPTeam()
    t3 = Team()
    
    u1 = HaskellUser()
    u2 = PythonUser()
    
    t1.leader = u1 # ok
    t2.leader = u2 # ok
    t1.leader = u2 # not ok, exception
    t3.leader = u2 # ok
    
    # now , index
    
    print(Index(FunctionalTeam, 'leader', u2)) # -> [t2]
    print(Index(Team, 'leader', u2)) # -> [t2,t3]
    

So, it works great (implementation details ommitted, but there is nothing
complicated) besides of this unholy circular import thing.


Answer: Circular imports are not inherently a bad thing. It's natural for the `team`
code to rely on `user` whilst the `user` does something with `team`.

The worse practice here is `from module import member`. The `team` module is
trying to get the `user` class at import-time, and the `user` module is trying
to get the `team` class. But the `team` class doesn't exist yet because you're
still at the first line of `team.py` when `user.py` is run.

Instead, import only modules. This results in clearer namespacing, makes later
monkey-patching possible, and solves the import problem. Because you're only
importing the _module_ at import-time, you don't care than the _class_ inside
it isn't defined yet. By the time you get around to using the class, it will
be.

So, test/users.py:

    
    
    import test.teams
    
    class User:
        def setTeam(self, t):
            if isinstance(t, test.teams.Team):
                self.team = t
    

test/teams.py:

    
    
    import test.users
    
    class Team:
        def setLeader(self, u):
            if isinstance(u, test.users.User):
                self.leader = u
    

`from test import teams` and then `teams.Team` is also OK, if you want to
write `test` less. That's still importing a module, not a module member.

Also, if `Team` and `User` are relatively simple, put them in the same module.
You don't need to follow the Java one-class-per-file idiom. The `isinstance`
testing and `set` methods also scream unpythonic-Java-wart to me; depending on
what you're doing you may very well be better off using a plain, non-type-
checked `@property`.

