oship-dev team mailing list archive

[Diego Manhães Pinheiro <dmpinheiro@xxxxxxxxx>]

Em 14 de março de 2010 02:41, Eduardo César <xcesar@xxxxxxxxx> escreveu:

> Hi all,
>
> Hello!

> Thank you Sergio and Luciana for the answers. I did a little research in
> the web about the subject of circular references in python and there seems
> to be a consensus between various developers about the non triviality of
> this particular problem in the python language.
> As far as I know, the python language lacks a support for circular
> references, and there is no guarantee that we can implement them by standard
> ways. Perhaps a clever hack would be the answer we need, but I don't really
> know how to do this. In this matter, I would like to see more about what the
> Zope/Grok and python experts have to say and perhaps we can come up with a
> solution.
>
> If you split the circular problem in two python files and put the imported
references at the END of the files, it works. In general, developers don't
like this solution because a import statement at the end of a file is a
inconvenient organization, but the circular problem is a a implementation
problem of the python interpreter. This is unique solution that i know.
Just to remind : the circular problem is a implementation concern. If a
diferent approach is mandatory, there's a way to customize the import
process using hooks provided since 2.3, according to the PEP[2], but a I
haven't use it yet .

Cheers
> Eduardo
>
> 2010/3/13 Luciana Tricai Cavalini <lutricav@xxxxxxxxx>
>
>  Hi all,
>>
>> Let me try to say something about what I've heard from Tim about this
>> "circular importing" problem.
>> The fact is that, so far, no Zope application development had to deal with
>> such a complex hierarchy as the implementation of the openEHR
>> specifications.
>> Tim has discussed it over and over again on the Zope and Grok developer's
>> lists and they often told him that OSHIP was "overengeneered".
>> This is a lack of understanding about the specific complexity of
>> healthcare information, and especially how multilevel modeling has to be
>> implemented for healthcare, which is the best (only?) way to deal with the
>> complexity of healthcare information.
>> Despite the fact that ZODB solves the persistence problems that all other
>> openEHR implementations seems to struggle with, fact is that nodoby in the
>> planet have ever implemented something so complex in Zope/Grok as OSHIP, as
>> far as we know.
>> Thus, dealing with those "circular import" problems is still work in
>> progress for us.
>> So, yes, Sergio, as far as I know, the current configuration is the only
>> solution Tim found.
>> I am not sure about how detailed this whole circular import problem and
>> its solution is described in the OSHIP developer's guide, but we need to
>> take a look.
>> We have Zope/Grok experts in the project now; this is something that I
>> think they could contribute to. I am sure Tim would appreciate that. Not to
>> mention the improvement to the project as a whole.
>>
>> Cheers, Luciana.
>>
>>
>> Sergio Miranda Freire escreveu:
>>
>>  Hi Eduardo,
>>
>>
>>
>> Ever since Oship began, Tim has been complaining about this kind of
>> problem. In the first versions, he had arranged all classes in separated
>> directories and files, according to its package structure. Later for reasons
>> that I ignore he has moved to the current configuration. He had to change
>> the schema of some attributes in order to avoid the problem you have just
>> mentioned. In this case, parent in IEvent is defined as being an IObjectRef.
>> Possibly this may happen somewhere else. This was the solution Tim found. I
>> don´t know if there is an alternative. Maybe it is another case to go into
>> the implementation guide.
>>
>>
>>
>> Cheers,
>>
>>
>>
>> Sergio
>>
>>
>>
>> *De:* oship-dev-bounces+sergio=lampada.uerj.br@xxxxxxxxxxxxxxxxxxx [
>> mailto:oship-dev-bounces+sergio=lampada.uerj.br@xxxxxxxxxxxxxxxxxxx<oship-dev-bounces+sergio=lampada.uerj.br@xxxxxxxxxxxxxxxxxxx>]
>> *Em nome de *Eduardo César
>> *Enviada em:* sábado, 6 de março de 2010 01:44
>> *Para:* OSHIP-Dev
>> *Assunto:* [Oship-dev] Egg and chicken
>>
>>
>>
>> Hi,
>>
>> In datastructures.py, in the class IEvent, the attribute "parent" needs to
>> be defined as of type "IHistory".
>> But there is a catch because the class IHistory has some attributes that
>> are of type IEvent.
>>
>> If I try to define "parent" with the correct type, the interpreter
>> complains that IHistory is not defined yet. If I exchange the order of the
>> classes, the interpreter complains that IEvent is not defined. Right now,
>> "parent" is defined of being of another type, for things to work.
>>
>> I am wondering how I can solve this... someone has any hints?
>>
>> Cheers
>> Eduardo
>>
>> --
>> Esta mensagem foi verificada pelo sistema de antivírus e
>> acredita-se estar livre de perigo.
>>
>> ------------------------------
>>
>> _______________________________________________
>> Mailing list: https://launchpad.net/~oship-dev <https://launchpad.net/%7Eoship-dev>
>> Post to     : oship-dev@xxxxxxxxxxxxxxxxxxx
>> Unsubscribe : https://launchpad.net/~oship-dev <https://launchpad.net/%7Eoship-dev>
>> More help   : https://help.launchpad.net/ListHelp
>>
>>
>> --
>> Esta mensagem foi verificada pelo sistema de antivírus e
>> acredita-se estar livre de perigo.
>>
>
>
> _______________________________________________
> Mailing list: https://launchpad.net/~oship-dev<https://launchpad.net/%7Eoship-dev>
> Post to     : oship-dev@xxxxxxxxxxxxxxxxxxx
> Unsubscribe : https://launchpad.net/~oship-dev<https://launchpad.net/%7Eoship-dev>
> More help   : https://help.launchpad.net/ListHelp
>
>
[1] - http://www.python.org/dev/peps/pep-0302/

-- 
http://dmpinheiro.blogspot.com
-----------------------------------
Diego Manhães Pinheiro
Linux User #375020