13

I have two classes that refer to each other, but obviously the compiler complains. Is there any way around this?

EDIT

Actually my code is slightly different than what Hank Gay uses. So python can definitely deal with some kinds of circular references, but it tosses an error in the following situation. Below is what I've got and I get an 'name Y not defined error'

class X(models.Model):

        creator = Registry()
        creator.register(Y)

class Y(models.Model):
    a = models.ForeignKey(X)
    b = models.CharField(max_length=200)

Hope this helps clarify. Any suggestions.

6
  • 4
    What's “obvious”? Where does it complain? Show code? Circular references are no problem for Python, the problem lies elsewhere. – Konrad Rudolph Jun 25 '09 at 20:43
  • What does the code look like? – Robert Harvey Jun 25 '09 at 20:43
  • What is here circular? Y does not reference X at all as much I can see! – Juergen Jun 25 '09 at 21:24
  • In Y ... a = models.ForeignKey(X) – Daniel Jun 25 '09 at 21:29
  • 1
    Please post ALL the relevant code. – S.Lott Jun 25 '09 at 21:51
22

In python, the code in a class is run when the class is loaded.

Now, what the hell does that mean? ;-)

Consider the following code:

class x:
    print "hello"
    def __init__(self): print "hello again"

When you load the module that contains the code, python will print hello. Whenever you create an x, python will print hello again.

You can think of def __init__(self): ... as equivalent with __init__ = lambda self: ..., except none of the python lambda restrictions apply. That is, def is an assignment, which might explain why code outside methods but not inside methods is run.

When your code says

class X(models.Model):
    creator = Registry()
    creator.register(Y)

You refer to Y when the module is loaded, before Y has a value. You can think of class X as an assignment (but I can't remember the syntax for creating anonymous classes off-hand; maybe it's an invocation of type?)

What you may want to do is this:

class X(models.Model):
    pass
class Y(models.Model):
    foo = something_that_uses_(X)
X.bar = something_which_uses(Y)

That is, create the class attributes of X which reference Y after Y is created. Or vice versa: create Y first, then X, then the attributes of Y which depend on X, if that's easier.

Hope this helps :)

2

The error is that execution of creator.register(Y) is attempted during the (executable) definition of class X, and at that stage, class Y is not defined. Understand this: class and def are statements that are executed (typically at import time); they are not "declarations".

Suggestion: tell us what you are trying to achieve -- perhaps as a new question.

2

UPDATE: He changed the question after my answer. The currently accepted solution is better in light of the new question.

What are you saying is the problem?

class A(object):
    def __init__(self):
        super(A, self).__init__()


    def b(self):
        return B()


class B(object):
    def __init__(self):
        super(B, self).__init__()


    def a(self):
        return A()

This compiles and runs just fine.

1
  • 1
    Some additional information: This works, yes. But it comes with a price: It only works if you put all classes into a single file. This is quite inconvenient: It might be very pythonic, I don't know, but I do know it breaks with good OOP practice of using an own file for each (public) class. – Regis May Mar 31 '17 at 0:48
2

As long as you are working within a method you can access the class object.

Thus the example above has no problems if creator.register(Y) is moved inside __init__. However, you cannot have circular references to classes outside of methods.

1
  • 2
    This answer doesn't explain anything. It gives a "workaround" without understanding or explaining the real issue, which is explained in the answers by Jonas and John Machin. – Van Gale Jun 25 '09 at 21:57
0

As we well know, it looks like a self-evident contradiction that we try to imagine of two independent but inter-dependent entities just from a point of their birth in physical world. But, when it comes to the area of software, we often encounter this kind of issues so called 'circular or mutual references'. That may come more seriously in object-oriented design, in which inter-operating software elements are usually defined and related to one another in imitation of such a way as physical ones, but still as pure logical existences.

In many programming languages, these issues have been resolved by declaring to-be-referenced elements in time before their to-reference elements just in form of signatures (no body definitions) for functions or classes. However, that sort of evading tricks seems neither longer available nor useful for a script-based language like Python.

In Python, we'd better approach 'circular reference' in a view of software engineering, as follows:

  1. It's much better to redesign classes not circular if possible; there are several ways (e.g. class de- or composition, call-back function, observer or subscriber patterns, and etc.) to make references between elements occur within the same class, removed or inverse.

  2. In cases that linearizing some circular chains between elements might cause more serious problem in some aspect like quality or productivity, we can take another measure to separate their traditional construction phase into two: creating and structuring. For example, two persons in friends who are destined to have their birth absolutely after observing the other's birth can do in a way that they are first born and then have their friendship just before any meaningful and observable occasions happen. Note that if we face some extreme complexity or need some high degree of integrity in dealing with inter-aggregated objects, applying a Factory pattern will pay off.

0

This is a great question. Although others have already answered it, I will feel free to provide another example.

Consider this program.

@dataclass
class A:
    b: B

class B:
    def __init__(self):
        pass

b is now a class-level variable and this program does not work. The name B is not defined at the moment when the Python interpreter loads (executes) the code of class A. Unlike compiled languages (such as C/C++), interpreters execute the code from the beginning to the end of the file command by command, in one pass. Since Python needs to know what B is when it defines the class A, it fails. B is only defined later.

Now, consider a slightly different program.

class A:
    def __init__(self):
        self.b = B()

class B:
    def __init__(self):
        pass

b is now an object-level variable and this program works. Python still executes the code from the beginning to the end of the file in the single pass, however, now it does not need to know what B is at the moment it reads the self.b = B() line. This is because the __init__ method is executed only when someone wants to construct an object of class A. Since the construction of an object will happen somewhere later in the program (when B is already defined), __init__ will work fine when it is needed.

-3

The problem is most likely not Python. I would think it is an SQL issue. The classes are via an abstraction layer converted to an SQL query to create a table. You are trying to reference from one table another one that at the time does not exist yet.

In SQL you would solve this by creating the table first without the references and after that modify them to make those references,

However I am not sure about my answer, so take it with lots of seasoning, I would be actually quite surprised if Django's database abstraction layer doesn't deal with cross references nicely.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.