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.
Circular imports are not inherently a bad thing. It’s natural for the
teamcode to rely onuserwhilst theuserdoes something withteam.The worse practice here is
from module import member. Theteammodule is trying to get theuserclass at import-time, and theusermodule is trying to get theteamclass. But theteamclass doesn’t exist yet because you’re still at the first line ofteam.pywhenuser.pyis 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:
test/teams.py:
from test import teamsand thenteams.Teamis also OK, if you want to writetestless. That’s still importing a module, not a module member.Also, if
TeamandUserare relatively simple, put them in the same module. You don’t need to follow the Java one-class-per-file idiom. Theisinstancetesting andsetmethods 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.