Hi Tim, Tim, you're reminding me of the old days when I programmed in Delphi, which also had this interesting ... errr ... "language feature". In Delphi's case, the root cause of the problem was that Delphi was a single-pass compiler; this helped make compilation blindingly fast, but also crippled the language in this respect. The standard work-around in Delphi was to put the two classes or interfaces in the same module, and possibly to declare a "forward reference" to one of the interfaces within that module.
In Python's case, I imagine that the root cause of the problem would be that it's an interpreted language. Is this why circular imports cause trouble in Python? Can you fix the problem by putting the two interfaces in the same module? A quick google for python "circular import" came up with a couple of other possible solutions: 1. Qualify the reference to the class name: http://mail.python.org/pipermail/python-list/2004-February/250192.html 2. Delay the import: http://www.velocityreviews.com/forums/t335136-circular-import.html Does one of these work for you? - Peter P.S. Your posts to the mailing lists are always interesting, Tim, but those of us using Microsoft Outlook (and its successor Windows Live Mail) have to go to considerable effort to read them, because the messages appear empty with the content as an attachment. I realise that this is because of a defect in those applications, but you are one of only two people in all the various lists that I subscribe to who send emails in this form, so I'm certainly not going to all the trouble of moving to a new email client. I know of one person who simply deletes your posts because of this issue. (For the benefit of people using these email clients, I've manually pasted your message in full below.) -------------------------------------------------- From: "Tim Cook" <[email protected]> Sent: Friday, July 04, 2008 5:50 AM To: "For openEHR implementation discussions" <openehr-implementers at openehr.org>; "For openEHR technical discussions" <openehr-technical at openehr.org> Cc: "ref_impl_python" <ref_impl_python at openehr.org> Subject: Redux: Circular Imports Hi All, This is different than the issues brought up by Rong in the Java implementation. I brought this up before when reading the specs. But now as my code has matured my fears are confirmed. Using Python: In an interface I define attributes of a class. In addition to some meta-data I define the 'type' of that attribute. Code is here; http://www.openehr.org/wsvn/ref_impl_python/TRUNK/oship/src/oship/openehr/am/archetype/?rev=0&sc=0 For example in IArchetype (the Archetype interface) I define ontology as an ArchetypeOntology type. Now Archetype of course is supposed to implement IArchetype. IArchetypeOntology defines parentArchetype as an Archetype type. This creates a circular dependency when the interfaces try to create a datatype based on a class that depends on itself. The same thing happens with DvMultimedia.thumbnail being of the DvMultimedia type. Other languages may handle these issues differently but I'll be surprised if the same issue isn't raised in the Ruby implementation??? I have tried various delayed import approaches but they do not solve this problem. My solution for Archetype.parentArchetype is to make it an ArchetypeId type. My solution for DvMultimedia.thumbnail is to create a Thumnbnail class that mirrors DvMultimedia without the thumnbnail attribute. All thoughts, comments, suggestions are welcome. Cheers, Tim -- Timothy Cook, MSc Health Informatics Research & Development Services LinkedIn Profile:http://www.linkedin.com/in/timothywaynecook Skype ID == timothy.cook ************************************************************** *You may get my Public GPG key from popular keyservers or * *from this link http://timothywayne.cook.googlepages.com/home* **************************************************************
