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.
Changing the name of the Working file different from the module which is imported in the script can avoid the Circular Imports problem. Import the module: Avoid importing objects or functions from a module that can cause Circular Imports. It is good to import the whole module to avoid the Circular Import.
Let's import the functions particularly instead of the whole file. To avoid circular import errors, you can move ```from module import X``` to a place it is needed.
In simplest terms, a circular import occurs when module A tries to import and use an object from module B, while module B tries to import and use an object from module A. You can see it on on an example with simple modules a.py and b.py: # a.py snippet. print('First line of a.py') from package.
also just as a reference, it seems circular imports are allowed on python 3.5 (and probably beyond) but not 3.4 (and probably bellow).
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
.
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With