Re: [zope.interface bug] Re: [Zope-dev] zope.interface confuses Python

2008-01-10 Thread Dieter Maurer
Jim Fulton wrote at 2008-1-7 16:04 -0500:
 ...
   inspect.getmembers and inspect.classify_class_attrs
   require that for each name in dir(cls) getattr(cls, name)
   does not raise an exception.

 This fails for classes magically stuffed with a __provides__
 descriptor.

It also fails for any descriptor that sometimes raises attribute  
errors.  Someone should report this as an inspect bug.

I filed a bug report for zope.interface
and for inspect (http://bugs.python.org/issue1785;)



-- 
Dieter
___
Zope-Dev maillist  -  Zope-Dev@zope.org
http://mail.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists - 
 http://mail.zope.org/mailman/listinfo/zope-announce
 http://mail.zope.org/mailman/listinfo/zope )


Re: [zope.interface bug] Re: [Zope-dev] zope.interface confuses Python

2008-01-10 Thread Jim Fulton


On Jan 10, 2008, at 12:44 PM, Dieter Maurer wrote:


Jim Fulton wrote at 2008-1-7 16:04 -0500:

...

 inspect.getmembers and inspect.classify_class_attrs
 require that for each name in dir(cls) getattr(cls, name)
 does not raise an exception.

This fails for classes magically stuffed with a __provides__
descriptor.


It also fails for any descriptor that sometimes raises attribute
errors.  Someone should report this as an inspect bug.


I filed a bug report for zope.interface
and for inspect (http://bugs.python.org/issue1785;)



Much thanks!

Jim

--
Jim Fulton
Zope Corporation


___
Zope-Dev maillist  -  Zope-Dev@zope.org
http://mail.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists - 
http://mail.zope.org/mailman/listinfo/zope-announce

http://mail.zope.org/mailman/listinfo/zope )


[Zope-dev] zope2 webdav memory usage...

2008-01-10 Thread Chris McDonough

Hi folks,

While messing with Zope2's webdav implementation, I ran across this  
bit of memory-management code:


   dflag = hasattr(ob, '_p_changed') and (ob._p_changed == None)
   ... stuff ...
   if dflag:
   ob._p_deactivate()

I actually think this should be:

   dflag = not getattr(ob, '_p_changed', None)
   ... stuff ...
   if dflag:
   ob._p_deactivate()

.. because when _p_changed on a persistent object (as I read it in the  
persistence interface file) is None, the object is a ghost.  The  
object will never be a ghost here because non-_p_ attributes are  
looked up on it before we check for _p_changed, and even if it was a  
ghost, deactivating a ghost (to turn it into a ghost) is just not  
useful.  I think the only time we don't want to deactivate it is if it  
has been changed (when _p_changed is True).  Or at least that seems to  
be the intent.


Does this sound right?  I have a feeling the answer will be crickets,  
but I figure what the heck.


- C

___
Zope-Dev maillist  -  Zope-Dev@zope.org
http://mail.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists - 
http://mail.zope.org/mailman/listinfo/zope-announce

http://mail.zope.org/mailman/listinfo/zope )


Bad memory z2/cmf memory mgmt pattern (was Re: [Zope-dev] zope2 webdav memory usage...)

2008-01-10 Thread Chris McDonough
After a little further digging, I've found that code of the same ilk  
exists in Zope 2's OFS.FindSupport, App.DavLockManager,  
Products.ZCatalog.ZCatalog and Products.ZCatalog.CatalogAwareness.   
Variants on the theme exist in CMFCore.CMFCatalogAware as well as  
CMFCore.WorkflowTool.  As far as I can tell, wherever memory  
management through deactivation is employed in Zope 2 and CMF, it's  
done in a way that seems to have no useful effect, at least if my  
theory is right.


- C

On Jan 10, 2008, at 8:58 PM, Chris McDonough wrote:


Hi folks,

While messing with Zope2's webdav implementation, I ran across this  
bit of memory-management code:


  dflag = hasattr(ob, '_p_changed') and (ob._p_changed == None)
  ... stuff ...
  if dflag:
  ob._p_deactivate()

I actually think this should be:

  dflag = not getattr(ob, '_p_changed', None)
  ... stuff ...
  if dflag:
  ob._p_deactivate()

.. because when _p_changed on a persistent object (as I read it in  
the persistence interface file) is None, the object is a ghost.  The  
object will never be a ghost here because non-_p_ attributes are  
looked up on it before we check for _p_changed, and even if it was a  
ghost, deactivating a ghost (to turn it into a ghost) is just not  
useful.  I think the only time we don't want to deactivate it is if  
it has been changed (when _p_changed is True).  Or at least that  
seems to be the intent.


Does this sound right?  I have a feeling the answer will be  
crickets, but I figure what the heck.


- C

___
Zope-Dev maillist  -  Zope-Dev@zope.org
http://mail.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists -http://mail.zope.org/mailman/listinfo/zope-announce
http://mail.zope.org/mailman/listinfo/zope )



___
Zope-Dev maillist  -  Zope-Dev@zope.org
http://mail.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists - 
http://mail.zope.org/mailman/listinfo/zope-announce

http://mail.zope.org/mailman/listinfo/zope )