Re: ZClass problem in 2.8 (Was: Re: [Zope-dev] Upcoming Zope 2.8 release)
Jo Meder wrote: A long time ago, Shane posted a very useful function to analyse acquisition wrappers: "showaq". Maybe, the mailing list archive is still able to locate his post... Just ask Google: http://www.zope.org/Members/chrisw/showaq Thanks Jo. It seems though that there was a branch containing further ZClass fixes that was merged into Zope 2.8 final that wasn't in b2 that fixed this problem. JB. ___ 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: ZClass problem in 2.8 (Was: Re: [Zope-dev] Upcoming Zope 2.8 release)
Dieter Maurer wrote: Looks like an acquisition bug: obj.aq_inContextOf(context, 1) is recursively defined by: True, if "obj.aq_base == context.aq_base" or "container(obj) is not None" and "container(obj).aq_inContextOf(context, 1)" where "container(obj)" is "aq_parent(aq_inner(obj))" which is the container containing "obj". which is equivalent to (resolving the recursing): obj.aq_inContextOf(context, 1) iff for some (hierarchie) ancestor "a" of obj, "a.aq_base == context.aq_base". Given this definition, you can check which implementation is wrong and file a bug report. Looking at the relevant *Acquisition.c files, both implementations of aq_inContextOf(2.7.6 & 2.8.0b2) are identical. The implementation of macros used in this method (isWrapper, WRAPPER, and OBJECT) are also identitcal, there being nothing else immediately obvious that looks like it could have been implemented differently there. I would hence suspect the wrapping, and/or behaviour of the object and/or context to be somehow different? JB. ___ 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-Coders] ZClass problem in 2.8 (Was: Re: [Zope-dev] Upcoming Zope 2.8 release)
Andreas Jung wrote: According to Jim ZClasses are working. A possibly isolated bug in ZClasses is bad but there are in general lots of such bugs in Zope. So > this is not a release stopper for me now. As far as I can see this is either a serious bug with respect to ZClasses in that they just don't work, or something I'm not doing quite right WRT Zope 2.8. My understanding from discussions on zope-dev was that 'ZClasses not working' was a blocker for a release of Zope 2.8.0 final? As an aside, I have tried this on an older Red Hat 32bit linux box and reproduced the same problem, so it doesn't appear to be a 64bit specific problem as I indicated it could be in my previous email. We have discussed ZClasses already and about how ZClasses can be maintained in the future. Since I see little commitment to ZClasses (except from Jim) ZClasses are not really a blocker for *this* 2.8.0 release. We defered this release already a bunch of times and it is now time to get 2.8.0 with Five and MVCC support to people. This is much, much more important for Zope than having to care about ZClasses. People can stick with Zope 2.7 if there is a problem for them with ZClasses in the hope that someone fixes outstanding ZClasses in a further 2.8 release. I don't care getting some beatings for my opinon that ZClasses are a neat ancient toy but not the tool of choice for nowadays Zope applications. We need a strong ZODB with MVCC and we need Five to bridge the world to Zope 3. And therefore ZClasses are absolutely not a reason to block the 2.8.0 release. We are currently using ZClasses, but also really want to be able to use MVCC. I am happy to help out where possible to get ZClasses going in 2.8 if I can get some guidance as to how to go about it. It looks to be a reasonably 'intricate' problem. At the end of the day, I'm actually not concerned about which release this fix (if needed) gets into. The most important thing from my PoV is resolving this for a version of Zope 2.8(+) (even just a branch) soon. I agree that there is a lot of 'good' in Zope 2.8 that should be made available to the wider community in the form of a final release ASAP. Thanks, JB. ___ 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 )
ZClass problem in 2.8 (Was: Re: [Zope-dev] Upcoming Zope 2.8 release)
Andreas Jung wrote: <[EMAIL PROTECTED]> wrote: What about the ZClasses? Jim fixed them (hopefully :-)) They don't work for me in 2.8... :-( I can't shake a new permission problem when trying to add a ZClass instance in 2.8b2. This is a 2.8 specific problem as the same process works in 2.7.6. For reference, the recently enabled tests for ZClasses all pass fine. This is a problem wether python or C security control is enabled via zope.conf. Also this was always tried with a 'fresh' ZODB. From a bit of digging through the code it seems there is a difference comes about in the call on line 166 of AccessControl.User inside _check_context : return object.aq_inContextOf(context, 1) In Zope 2.8 it returns 0, in 2.76 it returns 1 with the steps below. I don't know how to even start to try to debug inside this C based method? Below are the steps I used to reproduce this problem. This was on a Fedora Core 3 x86_64 server with a fresh Zope & Python compile : - Open the ZMI and login as a user with 'Manager' permissions. - Goto : /Control_Panel/Products/ - Add a new Product 'AAA' - Go to the Product : /Control_Panel/Products/AAA/ - Add a new 'Z Class' : id=ZZZ title=ZZZ meta type=ZZZ 'Create Constructor objects' checked 'Included standard Zope persistent object base classes' checked. - Goto the Root Folder - Goto the Security Tab - Give 'Manager' permission to 'Add ZZZs' - Goto the Root Folder - Try to add an instance of a 'ZZZ': - Zope 2.7.6 succeeds no problem. - Zope 2.8.0-b2 (and b1) you get a http auth login form come up. - You get the same behaviours with Python 2.3.5 and 2.4.1. I also tried a quick hack to make the above method always return 1 in Zope 2.8, but another error is then encountered whilst trying to add the ZClass instance : * Module ZPublisher.Publish, line 187, in publish_module_standard * Module ZPublisher.Publish, line 144, in publish * Module ZPublisher.Publish, line 107, in publish * Module Zope2.App.startup, line 248, in recordMetaData * Module OFS.Traversable, line 104, in getPhysicalPath * Module App.FactoryDispatcher, line 90, in __getattr__ AttributeError: getPhysicalPath I didn't see anything different you 'need' to do with 2.8 WRT ZClasses for this to work, but I suppose I could have missed something! One other note is that I have also only been able to try this on 64 bit platforms (Solaris 10 and FC3 as above). Thanks for any help. I hope this can be resolved before 2.8 goes final! JB. ___ 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-dev] Catalog performance
[EMAIL PROTECTED] wrote: Just my 2 cents observation... I ran this code and monitored the page "Cache extreme detail" in ZMI > ControlPanel > DebugInfo. With this method, the object was not loaded. However the intermediate objects that the unrestrictedTraverse() passed by were loaded into memory. e.g. If doc.getPath() is '/x/y/z/myobject', myobject was not loaded but x, y, and z were loaded into memory. This is a good point, and for catalog based retrievals of objects may be difficult (but not impossible) to avoid excess objects remaining in the cache. If however you are doing a walk of part of your ZODB tree (unlike 'randomly' accessing objects from the ZODB like this) you could ensure that you do a depth first traversal, then as you come back up the tree, traversed nodes that weren't active before the walk would be deactivated. eg something like this external method : def traverseTree(self): ''' Traverse the tree and do something. ''' was_ghost = self._p_changed is None for ob in self.objectValues(): traverseTree(ob) # XXX Do something with self here : self.doSomething() if was_ghost:self._p_deactivate() This should ensure that any 'traversed over' nodes that were previously not active are de-activated. JB. ___ Zope-Dev maillist - [EMAIL PROTECTED] 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-dev] Catalog performance
Chris Withers wrote: John Barratt wrote: docs = container.portal_catalog(meta_type='Document', ...) for doc in docs: obj = doc.aq_parent.unrestrictedTraverse(doc.getPath()) was_ghost = obj._p_changed is None value = obj.attr if was_ghost:obj._p_deactivate() Bear in mind though, that you can only do this in an external method... Why can you only do this in an external method? This idea (deactivating objects) is used quite a extensively in many parts of core zope such as OFS.ObjectManager as I mentioned in another post, and we use it in our product code quite a bit as well. JB. ___ Zope-Dev maillist - [EMAIL PROTECTED] 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-dev] Re: Catalog performance
Simon Michael wrote: > John Barratt wrote: > >> the problem (which seems likely) then you can ghostify the objects >> that were ghosts to begin with, and it will save memory (unless all >> those objects are already in cache). > > > This is rather interesting, but I don't quite follow what's happening. > If you can say a little more, or suggest a doc reference, I'm all ears. In general when an object is first loaded from the ZODB it is in a 'ghost' state, and is only a shell, it has no attributes etc. When you access (almost) any attribute on that object (eg. do : value = ob.attr), it gets activated (the contents are loaded automatically, and then the value returned). This is when the real memory usage takes place. So if you get an object from the ZODB and don't access any attributes, it will remain in a ghosted state. Some core python attributes *don't* cause it to activate such as accessing __dict__, and also clearly the reserved persistent _p_* attributes. If you look at the Cache Paramaters tab of your Database in the Control Panel (at least with Zope 2.6.2, perhaps 2.6.1) you can see how many objects are in memory, and how many are just 'ghosts'. I think ghosts are only 'removed' after a restart, and essentially just contain a _p_oid that references the object in the ZODB, ready for re-activation. A general reference for the ZODB can be found here that explains more : http://www.python.org/workshops/2000-01/proceedings/papers/fulton/zodb3.html An example use (and good discussion) that is similar, can be found at the link below. I found this after having problems with objects not de-ghostifying properly when just accessing __dict__ : http://aspn.activestate.com/ASPN/Mail/Message/zodb-dev/913762 Also a grep through the zope source code & some products will also find many examples of 'deactivating' objects after a 'walk' : eg. From OFS.ObjectManager : def manage_afterAdd(self, item, container): for object in self.objectValues(): try: s=object._p_changed except: s=0 if hasattr(aq_base(object), 'manage_afterAdd'): object.manage_afterAdd(item, container) if s is None: object._p_deactivate() A change to my example code that would be advisable is the wrapping of the _p_changed test in a try/except incase the object is None, or for some reason isn't persistent, and hence doesn't have a _p_changed. I hope this helps & makes sense! Cheers, JB. ___ Zope-Dev maillist - [EMAIL PROTECTED] 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-dev] Catalog performance
Max M wrote: Nguyen Quan Son wrote: > Hi, > I have a problem with performance and memory consumption when trying to do some statistics, using following code: > ... > docs = container.portal_catalog(meta_type='Document', ...) > for doc in docs: > obj = doc.getObject() > value = obj.attr > ... > > With about 10.000 documents this Python script takes 10 minutes and more than 500MB of memory, after that I had to restart Zope. I > am running Zope 2.6.1 + Plone 1.0 on Windows 2000, Xeon P4 with 1GB RAM. > What's wrong with this code? Any suggestion is appreciated. > Nguyen Quan Son. Most likely you are filling the memory of your server so that you are swapping to disk. Try cutting the query into smaller pieces so that the memory doesn't get filled up. If you can't use catalog metadata as Seb suggests (eg. you are actually accessing many attributes, large values, etc.) and if indeeed memory is the problem (which seems likely) then you can ghostify the objects that were ghosts to begin with, and it will save memory (unless all those objects are already in cache). The problem with this strategy though is that doc.getObject() method used in your code activates the object and hence you won't know if it was a ghost already or not. To get around this you can shortcut this method and do something like : docs = container.portal_catalog(meta_type='Document', ...) for doc in docs: obj = doc.aq_parent.unrestrictedTraverse(doc.getPath()) was_ghost = obj._p_changed is None value = obj.attr if was_ghost:obj._p_deactivate() You can test this by running your code on a freshly restarted server, and check the number of objects in cache. The number shouldn't change much after running the above method, but will increase dramatically if you just used 'obj = doc.getObject()' instead, or didn't do the deactivating of the objects. The lower number of objects in your cache should in turn keep your memory usage down, and prevent your computer paging through the request, and hence speed things up considerably! Another option would be to reduce the size of your cache so that the amount of memory your zope instance consumes doesn't cause your computer to swap, though doing the above code changes will also help keep your cache with the 'right' objects in it as well, which in turn will further help with the performance of subsequent requests. Cheers, JB. ___ Zope-Dev maillist - [EMAIL PROTECTED] 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-dev] How to override __getattr__ and not break acquisition
> There is no "default" or "normal" __getattr__. __getattr__ is defined only > when you need "abnormal" ways of getting an attribute. Do you mean it only gets defined when standard (instance & class based) searching methods fail? > > If I try a similar thing to this, I always end up getting the 'old' one > > being defined as just the 'raise' statement. > > Thats because ObjectManager doesn't have a __getattr__ . The good > thing with Object Manager doesn't specifically, but Implicit does, you can see it if you print out its '__class__.__dict__'. > this is that you don't have to bother about calling the normal __getattr__. > You only need to implement __getattr__ if you want data that isn't > attributes and has names that are only defined in runtime, to look like they > are attributes. Exactly what I need! :-) Thankfully these methods that I need defined at runtime only come from one other object, so it appears I can override the __of__ method to work the magic for me in conjunction with containment acquisition. Thanks, JB. ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] How to override __getattr__ and not break acquisition
Casey Duncan wrote: > __getattr__ hooks are evil, only to be used as a last resort. Are you So I've found, >and heard! It didn't stop me from tyring, and I still don't see why they should be >so hard so work with, difficult perhaps, but I wouldn't have though you needed to >pull the seemingly impossible to have them work (with zope at least)! >creating some sort of transparent proxy object? What exactly are you >trying to do? I'm not getting a big picture here. And why do you need See my last post (I posted it before I saw this one sorry), but basically I want a link/reference type functionality that hooks in before containment acquisition, and I think I've worked it out another way to do it as per that post. >to call the inherited __getattr__ from Implicit? Doesn't raising an >AttributeError take care of this? Yes it does, but it wasn't so simple in this case (This is where the 'evil' you mentioned earlier comes in). Part of my problem was the need to call another class method on self which in turn needs to access a method on self that comes from containment acquisition on self, which would call my overridden __getattr__ and have an exception rasied due to not doing containment acquisition. This exeption would then be caught in the code calling the first __getattr__ call, and not the second. Can python not handle exceptions properly with recursive function calls, or was this my bad analysis and/or just being generally confused? > > One other way that may work is to be able to set methods on the object > > as it comes out of the ZODB for use, as I need to be able to get methods > > from other objects in the ZODB, something to explore... Anyone have any > > pointers on this one perhaps? > > Yes, but that would change the attributes and cause the ZODB to save >them on commit (unless you use volatile '_v_' attrs). This might not be >a bad thing. I might be able to use _v_ attrs, otherwise the storing bit would be very bad unless the store method was also overriden and they were deleted on the way out. Thanks, JB. ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] How to override __getattr__ and not break acquisition
Steve, Thanks for the reply. Steve Alexander wrote: > Sounds like you could use ZPatterns. We already use ZPatterns, but that doesn't seem to fit in at the right layer unfortunately. To further clarify... I am trying to do something similar to what is implemented in Dieter Maurer's 'Reference' product (ie. access another object via a link/reference), and be able to check elswhere for a method/attribute and return it in preference to acquisition (both containment & context based), but not break the acquisition. When I first looked at this product I didn't think it did this quite how I wanted, but I may not have been using it right, as then answer seems to be there, override the __of__ method, and ditch __getattr__! As it stands, I see (think) the standard attribute/method search happens for an Implicit derived class as follows : 1 - Check instance, self.__dict__ 2 - Check class, self.__class__.__dict__ 3 - Check base classes dict, self.__class__.__bases__ __dict__'s etc. 4 - If not found then look for a __getattr__ method and call it. This is implemented in Acquisition.Implicit (c based Extension Class). 5 - Implicit __getattr__ does containment aquisition, __of__. 6 - Implicit __getattr__ does context aquisition, __bobo_traverse__. Overriding __of__ by doing something like : def __of__(self, parent): if not hasattr(parent,'aq_base'): return self ob = self.getTarget() self = Acquisition.ImplicitAcquisitionWrapper(self, ob) self = Acquisition.ImplicitAcquisitionWrapper(self, parent) return self Seems to do the trick as it puts the referenced or linked object in the acquisition chain before the parent. I'm still curious as to know how to get this working with __getattr__ but this other way seems to achieve the same end, and in a similarly elegant fashion. JB. ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] How to override __getattr__ and not break acquisition
Oliver, Thanks for the reply. Oliver Bleutgen wrote: > > def __getattr__(self,attr): > > if name = 'foo': > > return self.foo() > > > > return Implicit.__class__.__getattr__(self,attr) > > If you really want to do just that, take a look at ComputedAttribute, > just in case you don't know. > > foo = ComputedAttribute(_foo) > def _foo(self,..): > > return something I perhaps should have clarified that I need to be able to specify the name of the attributes or methods at run time, so ComputedAttribute unfortunately won't do the trick as you have to define each attribute/method you require in the class definition. ie. I need something like : def __getattr__(self,attr): if name in self.methodlist: return Implicit.__class__.__getattr__(self,attr) where self.methodlist is a list of strings that may change per instance and/or at runtime, or itself could be calculated at the time of doing the __getattr__ (eg self.getMethodList()). One other way that may work is to be able to set methods on the object as it comes out of the ZODB for use, as I need to be able to get methods from other objects in the ZODB, something to explore... Anyone have any pointers on this one perhaps? Thanks, JB. ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] How to override __getattr__ and not break acquisition
OK, a bit of python and Zope experimenting and I have got a little
further with this, and my understanding as to when __getattr__ is
actually called!
This gets closer to working, by calling the __getattr__ from the
Implicit base class, but could be barking up the wrong tree :
def __getattr__(self,attr):
if name = 'foo':
return self.foo()
return Implicit.__class__.__getattr__(self,attr)
Except I get a 'TypeError' on the call to the Implicit getattr :
"unbound C method must be called with ExtensionClass 1st argument"
'self' inherits from Implicit, so I would have thought this would be OK.
Anyone with any thoughts/pointers?
TIA,
JB.
John Barratt wrote:
>
> Dragging up and old topic here... But I am attempting something similar
> here with no success.
>
> Basically I want to do something like was demonstrated (using python
> 2.1, Zope 2.5.1), but to call the 'default' __getattr__ subsequently so
> that I can put in my own handlers, before looking for 'standard' attrs
> present on this object through the normal __getattr__ method :
>
> __oldgetattr__ = __getattr__
> def __getattr__(self, name):
> if name = 'foo':
> return self.foo()
>
> return self.__oldgetattr__(name)
>
> However just the assigment of __oldgetattr__ gives an attribute error.
> Looking at Andrew Milton's Portable Holes product it seems a similar
> attempt to do this is made :
>
> ...
> try:
> __oldgetattr__ = ObjectManager.__getattr__
> except:
> try:
> __oldgetattr__ = ObjectManager.inheritedAttribute('__getattr__')
> except:
> def __oldgetattr__(self, name):
> raise AttributeError, name
> ...
>
> If I try a similar thing to this, I always end up getting the 'old' one
> being defined as just the 'raise' statement. All other attempts to
> store the 'old' gettattr results in an attribute error. Is this simply
> not possible with this version of python and hence the current Zope
> release?
>
> Looks like with 2.2 you can do something like this (taken from Guido's
> presentation as OSCON 2001) :
>
> class C(object):
> def __getattr__(self, name):
> if name == 'x': return ...
> return object.__getattr__(self, name)
>
> Thanks for any help/pointers!
>
> JB.
>
> Casey Duncan wrote:
> >
> > If your __getattr__ fails to find what it wants, it should raise an
> > AttributeError. This will give the ball back to the acquisition
> > machinery.
> >
> > Thusly:
> >
> > def __getattr__(self, name):
> > if name = 'foo':
> > return self.foo()
> > raise AttributeError, name
> >
> > hth,
> >
> > -Casey
> >
> > On Tue, 2002-06-04 at 22:28, Erik A. Dahl wrote:
> > > Ok I need to override __getattr__ in one of my product classes. I'm
> > > sure this is killing acquisition but not sure about the persistence
> > > stuff (I think this is working). Is there a way to make this work?
> > > Here is what I'm doing:
> > >
> > > def __getattr__(self, name):
> > > if name == 'myattr':
> > > return self.myattr()
> > >
> > >
> > > I assume that somewhere in the Acquisition code there is a __getattr__
> > > but I can't find it. I tried calling Implicit.__getattr__ but its not
> > > there. If some one has an example that would be great.
> > >
> > > -EAD
> > >
> > >
> > >
> > > ___
> > > Zope-Dev maillist - [EMAIL PROTECTED]
> > > http://lists.zope.org/mailman/listinfo/zope-dev
> > > ** No cross posts or HTML encoding! **
> > > (Related lists -
> > > http://lists.zope.org/mailman/listinfo/zope-announce
> > > http://lists.zope.org/mailman/listinfo/zope )
> >
> > ___
> > Zope-Dev maillist - [EMAIL PROTECTED]
> > http://lists.zope.org/mailman/listinfo/zope-dev
> > ** No cross posts or HTML encoding! **
> > (Related lists -
> > http://lists.zope.org/mailman/listinfo/zope-announce
> > http://lists.zope.org/mailman/listinfo/zope )
>
> ___
> Zope-Dev maillist - [EMAIL PROTECTED]
> http://lists.zope.org/mailman/listinfo/zope-dev
> ** No cross posts or HTML encoding! **
> (Related lists -
> http://lists.zope.org/mailman/listinfo/zope-announce
> http://lists.zope.org/mailman/listinfo/zope )
___
Zope-Dev maillist - [EMAIL PROTECTED]
http://lists.zope.org/mailman/listinfo/zope-dev
** No cross posts or HTML encoding! **
(Related lists -
http://lists.zope.org/mailman/listinfo/zope-announce
http://lists.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] How to override __getattr__ and not break acquisition
Dragging up and old topic here... But I am attempting something similar
here with no success.
Basically I want to do something like was demonstrated (using python
2.1, Zope 2.5.1), but to call the 'default' __getattr__ subsequently so
that I can put in my own handlers, before looking for 'standard' attrs
present on this object through the normal __getattr__ method :
__oldgetattr__ = __getattr__
def __getattr__(self, name):
if name = 'foo':
return self.foo()
return self.__oldgetattr__(name)
However just the assigment of __oldgetattr__ gives an attribute error.
Looking at Andrew Milton's Portable Holes product it seems a similar
attempt to do this is made :
...
try:
__oldgetattr__ = ObjectManager.__getattr__
except:
try:
__oldgetattr__ = ObjectManager.inheritedAttribute('__getattr__')
except:
def __oldgetattr__(self, name):
raise AttributeError, name
...
If I try a similar thing to this, I always end up getting the 'old' one
being defined as just the 'raise' statement. All other attempts to
store the 'old' gettattr results in an attribute error. Is this simply
not possible with this version of python and hence the current Zope
release?
Looks like with 2.2 you can do something like this (taken from Guido's
presentation as OSCON 2001) :
class C(object):
def __getattr__(self, name):
if name == 'x': return ...
return object.__getattr__(self, name)
Thanks for any help/pointers!
JB.
Casey Duncan wrote:
>
> If your __getattr__ fails to find what it wants, it should raise an
> AttributeError. This will give the ball back to the acquisition
> machinery.
>
> Thusly:
>
> def __getattr__(self, name):
> if name = 'foo':
> return self.foo()
> raise AttributeError, name
>
> hth,
>
> -Casey
>
> On Tue, 2002-06-04 at 22:28, Erik A. Dahl wrote:
> > Ok I need to override __getattr__ in one of my product classes. I'm
> > sure this is killing acquisition but not sure about the persistence
> > stuff (I think this is working). Is there a way to make this work?
> > Here is what I'm doing:
> >
> > def __getattr__(self, name):
> > if name == 'myattr':
> > return self.myattr()
> >
> >
> > I assume that somewhere in the Acquisition code there is a __getattr__
> > but I can't find it. I tried calling Implicit.__getattr__ but its not
> > there. If some one has an example that would be great.
> >
> > -EAD
> >
> >
> >
> > ___
> > Zope-Dev maillist - [EMAIL PROTECTED]
> > http://lists.zope.org/mailman/listinfo/zope-dev
> > ** No cross posts or HTML encoding! **
> > (Related lists -
> > http://lists.zope.org/mailman/listinfo/zope-announce
> > http://lists.zope.org/mailman/listinfo/zope )
>
> ___
> Zope-Dev maillist - [EMAIL PROTECTED]
> http://lists.zope.org/mailman/listinfo/zope-dev
> ** No cross posts or HTML encoding! **
> (Related lists -
> http://lists.zope.org/mailman/listinfo/zope-announce
> http://lists.zope.org/mailman/listinfo/zope )
___
Zope-Dev maillist - [EMAIL PROTECTED]
http://lists.zope.org/mailman/listinfo/zope-dev
** No cross posts or HTML encoding! **
(Related lists -
http://lists.zope.org/mailman/listinfo/zope-announce
http://lists.zope.org/mailman/listinfo/zope )
