[Zope] Class instances changing address?

[Dieter Maurer]

Jeff Gentry wrote at 2006-1-19 16:55 -0500:
> ...
>As background, the primary class (A) maintains a handle to an instance of
>another class (B) which handles interaction w/ a psycopg db
>controller.  Class A also will instantiate several instances of Class C
>and as part of the construction will pass it the handle to class B.  So in
>summary, A has a B and has 1:n C's, and C has a reference to B.  A & B
>have physical representations in the ZMI, while instances of C are
>'virtual'.
>
>What is happening at times is that all of a sudden any call from C to B
>(ie C is accessing the DB) will result in Zope reporting that it could not
>find the psycopg controller, and indeed when this happens, any call
>through B via C will show that B can not find any DB controllers (using
>SQLConnectionIDs()).  When I looked a bit closer, I had C's instance of B
>do a 'print instanceOfB' before calling out to B, which looked like this
>in the console:
><B instance at 2a9d564da0>
>
>What I found was at the moment that things stopped working, the address of
>the instance was changed, which explains a lot.

No object in Python can ever change its address.

  If you observe a "c.b" changing address, then this means that either

    *  you look at a different "c"

    *  a new value was assigned to "c.b" (by an explicit assignment
       and not be magic -- unless something skrewed the memory
       management).


Your "B instance" above, is apparently not acquisition wrapped.
Acquisition wrapped instances usually include the container path
in their "repr" (if the intermediate objects have an id/getId --
this is the case of instances with "ZMI representation" ("SimpleItem"s,
to be precise).

> However, I can not figure
>out why this would happen

Does your logfile contains unexplained entries?

Do you use "try: ... except: ..." and swallow valuable exception
information?

-- 
Dieter