problems with circular references

[Jim Dennis]

In article <a7tgkv$t3m$1 at web1.cup.hp.com>, jimh wrote:

>> It sounds as though somehow or other you want to put the
>> actual error number data for each class into MessageCatalog
>> and give the 50 classes some interface for registering
>> their error numbers with MessageCatalog.  Then MessageCatalog
>> is oblivious to what other classes there are, except that
>> at run time they tell it about themselves.  You could add
>> another object for holding the error number data
>> and have one instance per class---if that provides a convenient
>> structure for accessing the error number data...

>> susan

>I will have to think about that one.  When a class accesses the
>MessageCatalog, it may be requesting message text from _other_ classes'
>errors.  Also, these are often called from cgi scripts, so they are run as a
>one-shot deal.  Also(!), the case of an error is (theoretically) uncommon
>and the MessageCatalog is only instantiated if an error occurs.  That way,
>if no error occurs, there is no overhead with importing the MessageCatalog.

>One thought I had was to split out all the error numbers from the class
>files (kind of like .h versus .c files).  Then MessageCatalog.py would only
>import the ".h" files and I wouldn't have the circular import reference.
>However, that would add another 50(!) files.

>Jim

 That's abhorent!  Just put the list of 50 error codes in the
 MessageCatalog.py file directly.  Let all 50 modules (or other 
 scripts, or whatever they are) load that on demand (when they need
 their own or ANY other error code.  The message catalog module 
 can't possibly be big enough and/or slow enough to create any 
 measurable overhead for the various component scripts.  If there
 is any measurable latency then look at some sort fast CGI or
 mod_pyton, mod_snake or some other way to give these CGI scripts
 some persistence.