Re: [Zope-dev] __getattr__ and Acquisition

[Lennart Regebro]

From: "Andreas Kostyrka" <[EMAIL PROTECTED]>
> But my attributes are not normal. So I should generate them by
> __getattr__. Only by noticing that I could get the same effect by
> putting my attribute source in front of my object in the acquisition
> chain.
>
> The question is still, how does one a __getattr__ that needs (as a
> client) acquisition to calculate the attribute.

You don't. __getattr__ is used if you for example want data from a subobject
to behave like it's attributes directly on the object. Trying to get data
from another object in the ZODB to behave like they are attributes directly
on the object with __gettattr__ is problematic, because that is not what
it's designed for, and because in __getattr__ you don't have a context.

Making data from another object in the ZODB to behave like they are
attributes directly on the object is however exactly what Acquisition is
designed for, and hence it's easier to do it that way.

> (Basically __of__ works only if I do not need to know the attribute name

??? Why wouldn't it work if you know the attribute name? What it doesn't do
is to only work with some attributes, it works with all attributes, maybe
that is what you mean? This usually don't give you any negative side
effects.

> > I guess that depends on when you patch in the extra object in the
> > acquisition. If you do it in __of__() then I guess it's visible all the
>
> Well, where else can I patch it in?

Overriding __of__ means that you are changing how the acquisition chain
looks and behaves for the object. But you can also just wrap the object by
calling __of__ whenever you need it wrapped instead of overriding it.

If I remember the syntax correctly "foo = self.__of__(magickfolder)" would
wrap self in magickfolder, and make it acquire magickfolders attributes, so
that after doing this "foo.bla" would get the attribute from magickfolder if
it doens't exist on self. This you can do just before you need that
behaviour, and it will be a completely local behaviour.

Don't spank me if I don't remember all the details here, I haven't looked at
the code where we do this in a couple of months. :-) We insert our templates
in the acquisition chain when index_html is called, so that the correct
template is used when rendering. This insertion then only affects the
rendering.

From: "Dieter Maurer" <[EMAIL PROTECTED]>
>   "__getattr__" is used before acquisition comes into play.

You are probably correct. Nevertheless, you can't push acquired object into
the acqusition context in __getattr__, because the object inside __getattr__
has no context, and hence no objects are acquired. But of course it makes
sense that __getattr__ is called before the acquisition comes into play,
because otherwise you wouldn't be able to override acquired attributes. :-)




___
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] __getattr__ and Acquisition

[Dieter Maurer]

Lennart Regebro writes:
 > ...
 > Because that's not how it's supposed to work. You can override __getattr__
 > to have special magick attributes. Acquisition is not a special magick
 > attribute. __getattr__ is only called when an attribute aren't found in a
 > "normal" way, and in the context of Zope, Acquicistion would be regarded as
 > normal. :-)
I had written the exact same statement some time ago. Nevertheless, it is
wrong :(
Now, I know it better:

  "__getattr__" is used before acquisition comes into play.


Dieter

___
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] __getattr__ and Acquisition

[Andreas Kostyrka]

Am Mit, 2002-09-25 um 12.44 schrieb Lennart Regebro:
> From: "Andreas Kostyrka" <[EMAIL PROTECTED]>
> To: "Lennart Regebro" <[EMAIL PROTECTED]>
> > > You shouldn't, really.
> 
> > Why not?
> 
> Because that's not how it's supposed to work. You can override __getattr__
> to have special magick attributes. Acquisition is not a special magick
> attribute. __getattr__ is only called when an attribute aren't found in a
> "normal" way, and in the context of Zope, Acquicistion would be regarded as
> normal. :-)
But my attributes are not normal. So I should generate them by
__getattr__. Only by noticing that I could get the same effect by
putting my attribute source in front of my object in the acquisition
chain.

The question is still, how does one a __getattr__ that needs (as a
client) acquisition to calculate the attribute.
(Basically __of__ works only if I do not need to know the attribute name
and do not mind a changed acquisition chain, __getattr__ works only if I
do not need Acquisition, ...)

> > Done. Only thing I've noticed that the Catalog shows this "additional"
> > path elements, ...
> 
> I guess that depends on when you patch in the extra object in the
> acquisition. If you do it in __of__() then I guess it's visible all the
Well, where else can I patch it in?

Andreas
-- 
Andreas Kostyrka <[EMAIL PROTECTED]>


___
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] __getattr__ and Acquisition

[Lennart Regebro]

From: "Andreas Kostyrka" <[EMAIL PROTECTED]>
To: "Lennart Regebro" <[EMAIL PROTECTED]>
> > You shouldn't, really.

> Why not?

Because that's not how it's supposed to work. You can override __getattr__
to have special magick attributes. Acquisition is not a special magick
attribute. __getattr__ is only called when an attribute aren't found in a
"normal" way, and in the context of Zope, Acquicistion would be regarded as
normal. :-)

> Done. Only thing I've noticed that the Catalog shows this "additional"
> path elements, ...

I guess that depends on when you patch in the extra object in the
acquisition. If you do it in __of__() then I guess it's visible all the
time. This may or may not be a good idea. :)




___
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] __getattr__ and Acquisition

[Andreas Kostyrka]

Am Mit, 2002-09-25 um 10.06 schrieb Lennart Regebro:
> From: "Andreas Kostyrka" <[EMAIL PROTECTED]>
> > And how do I return an attribute that is acquired (but not down th main
> > acquisition path, but on a side line?)
> 
> You shouldn't, really.
Why not?
> 
> > I assume that I could probably play some silly games with __of__ to make
> > my additional Acquisition objects to come just before my object in the
> > acquisition path, ...
> 
> Yup, much better idea.
Done. Only thing I've noticed that the Catalog shows this "additional"
path elements, ...
See also www.zope.org/Members/yacc/FlexData ;), I've left the old
__getattr__ hack commented in the source, ...

Andreas
-- 
Andreas Kostyrka <[EMAIL PROTECTED]>


___
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] __getattr__ and Acquisition

[Lennart Regebro]

From: "Andreas Kostyrka" <[EMAIL PROTECTED]>
> And how do I return an attribute that is acquired (but not down th main
> acquisition path, but on a side line?)

You shouldn't, really.

> I assume that I could probably play some silly games with __of__ to make
> my additional Acquisition objects to come just before my object in the
> acquisition path, ...

Yup, much better idea.



___
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] __getattr__ and Acquisition

[Andreas Kostyrka]

Am Die, 2002-09-24 um 21.32 schrieb Dieter Maurer:
> Andreas Kostyrka writes:
>  > ...
>  > > __of__ is non-intuitive but it can work.
>  > So how do I call it?
>  > return myitem.__of__(self)
>  > Doesn't make sense, as self is not wrapped and as such DOES not contain
>  > any knowledge how it was accessed, ...
> Acquisition lookup is implemented by a recursive function:
> 
>   While you are right that "self" does not know how it was accessed,
>   the recursive lookup function does (on its runtime stack).
And how do I return an attribute that is acquired (but not down th main
acquisition path, but on a side line?)
I assume that I could probably play some silly games with __of__ to make
my additional Acquisition objects to come just before my object in the
acquisition path, ...
But still it seems to me, it could be nice if __getattr__ would be
called on an explicit wrapper of self, instead of the direct pure self.

Andreas
-- 
Andreas Kostyrka <[EMAIL PROTECTED]>


___
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] __getattr__ and Acquisition

[Dieter Maurer]

Jeffrey P Shell writes:
 > ...
 > The other problem with __getattr__ is interfacing with Persistence.  
 > ZODB handles it now, but it wasn't all that long ago that it couldn't.
But, it is unlikely that it will loose this capability again...


Dieter

___
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] __getattr__ and Acquisition

[Dieter Maurer]

Andreas Kostyrka writes:
 > ...
 > > __of__ is non-intuitive but it can work.
 > So how do I call it?
 > return myitem.__of__(self)
 > Doesn't make sense, as self is not wrapped and as such DOES not contain
 > any knowledge how it was accessed, ...
Acquisition lookup is implemented by a recursive function:

  While you are right that "self" does not know how it was accessed,
  the recursive lookup function does (on its runtime stack).

  And it will provide the missing context when it builds further
  wrappers on returning from the recursive calls.


Dieter

___
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] __getattr__ and Acquisition

[Dieter Maurer]

Andreas Kostyrka writes:
 > I've just discovered, that Acquisition does not work with __getattr__,
 > right?
It does, just not the way, you expect it:

  The actual attribute lookup (for attributes not starting with
  "aq_") is always made with an unwrapped object.
  That's the reason why the "self" in "getattr" is unwrapped.

  Special operations ensure for Python Methods (the one of
  "ExtensionClass" not Zope's!) that their "self" receives part
  of the acquisition context (it's rarely the full context,
  just enough to work in most cases).
  They are rebuild with the current node as "self", when the recursive lookup
  comes back out of "aq_self" iff the method's "self" is "aq_self".

You may have a look at my "Reference" product

  

There, I fight with the peculiarities of "__getattr__" and
acquisition context for methods.


Dieter

___
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] __getattr__ and Acquisition

[Jeffrey P Shell]

On Monday, September 23, 2002, at 09:14  AM, Andreas Kostyrka wrote:

> Am Mon, 2002-09-23 um 11.12 schrieb Florent Guillaume:
>> Anoter way to do that is to play games with __of__.
>> Look at the implementation of the skins tool in CMF for an example.
> Doesn't help, as I do NOT know my container :(
>
> Basically __getattr__ when called does not know it's containment
> anymore. :(

This is why my stock suggestion to needing to do anything with 
acquisition and __getattr__ (or any other acquisition jump-arounds) is: 
Don't.  There are a lot of complexities that can arise out of 
Acquisition, Wrappers, and so on, that really require a deep 
understanding of exactly HOW acquisition works, versus what it usually 
does.

The other problem with __getattr__ is interfacing with Persistence.  
ZODB handles it now, but it wasn't all that long ago that it couldn't.

But with Acquisition - once you go beyond "fair use", there's not 
enough Scotch in the world to kill the brain cramp.  :)


___
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] __getattr__ and Acquisition

[Leonardo Rochael Almeida]

On Sun, 2002-09-22 at 18:39, Andreas Kostyrka wrote:
> Hi!
> 
> I've just discovered, that Acquisition does not work with __getattr__,
> right?
> 
> (I assume that this is so because something like getattr(mybase,attr) is
> called during the acquisition process to prevent infinite recursion.)

I believe that is correct.

> 
> Anyway to get around that? (To basically get a wrapped self from
> somewhere?)

You might want to look at PortableHole for inspiration. It does get
around getattr problems with acquisition:

http://www.zope.org/Members/TheJester/PortableHole

Cheers, Leo

-- 
Ideas don't stay in some minds very long because they don't like
solitary confinement.


___
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] __getattr__ and Acquisition

[Andreas Kostyrka]

Am Mon, 2002-09-23 um 18.29 schrieb Florent Guillaume:
> Andreas Kostyrka  <[EMAIL PROTECTED]> wrote:
> > Am Mon, 2002-09-23 um 11.12 schrieb Florent Guillaume:
> > > Anoter way to do that is to play games with __of__.
> > > Look at the implementation of the skins tool in CMF for an example.
> > Doesn't help, as I do NOT know my container :(
> 
> Yes it does.
> __of__ is non-intuitive but it can work.
So how do I call it?
return myitem.__of__(self)
Doesn't make sense, as self is not wrapped and as such DOES not contain
any knowledge how it was accessed, ...
/site1/shared/a/b/c/x
/site2/shared/a/b/c/x
might be quite different things?

My problem especially is not generating a wrapper, but to acquire some
object from up my acquisition chain, ...

> 
> > Basically __getattr__ when called does not know it's containment
> > anymore. :(
> 
> You didn't look a the code I pointed to you. Look at CMFCore/Skinnable
> to be precise (not everything is to be used of course).
> 
> * In __of__ you store the parent in a volatile attribute,
> * in __getattr__ you lookup the volatile attribute
> 
> This works as long as your object is not used in several different
> acquisition contexts.
But exactly THIS I want to support. How should I know if the object will
not be used sometime in the future with different contexts. How can I
know that my content objects will not be recycled in a second Virtual
Host? etc.

Andreas





___
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] __getattr__ and Acquisition

[Andreas Kostyrka]

Am Mon, 2002-09-23 um 19.28 schrieb Florent Guillaume:
> But it's not necessarily a problem if you take care to use aq_inner.
> That depends on the use you have for the parent, really.
General Zope site? Basically I want this capability to be incorporated
in some general building class, ... 
So I cannot know what my users (that might be website developers) will
be doing with the gadget, right? Actually I could be in the unhappy
situation to be forced to share parts of websites I currently develop
with newly developed ones, ...

But __of__ is still a really nice trick :)

Andreas


___
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] __getattr__ and Acquisition

[Florent Guillaume]

On Mon, 2002-09-23 at 19:04, Johan Carlsson [Torped] wrote:
> At 16:29 2002-09-23 +, Florent Guillaume said:
> >You didn't look a the code I pointed to you. Look at CMFCore/Skinnable
> >to be precise (not everything is to be used of course).
> >
> >* In __of__ you store the parent in a volatile attribute,
> >* in __getattr__ you lookup the volatile attribute
> >
> >This works as long as your object is not used in several different
> >acquisition contexts.
> 
> Hi Florent,
> Would you care to elaborate on that last sentence? :-)
> Could you give an example when it wouldn't work?

Sure.

If your object with special __of__ and __getattr__ is o and you do
x = f.o
 #  o.__of__(f) is called so f is stored in o._v_stuff
y = f.g.o
 #  o.__of__(f.g) is called so f.g is stored in o._v_stuff
x['foo']
 # o's __getattr__ finds f.g stored in _v_stuff and not f.

But it's not necessarily a problem if you take care to use aq_inner.
That depends on the use you have for the parent, really.

Florent


-- 
Florent Guillaume, Nuxeo (Paris, France)
+33 1 40 33 79 87  http://nuxeo.com  mailto:[EMAIL PROTECTED]


___
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] __getattr__ and Acquisition

[Johan Carlsson [Torped]]

At 16:29 2002-09-23 +, Florent Guillaume said:
>You didn't look a the code I pointed to you. Look at CMFCore/Skinnable
>to be precise (not everything is to be used of course).
>
>* In __of__ you store the parent in a volatile attribute,
>* in __getattr__ you lookup the volatile attribute
>
>This works as long as your object is not used in several different
>acquisition contexts.

Hi Florent,
Would you care to elaborate on that last sentence? :-)
Could you give an example when it wouldn't work?
Best Regards,
Johan Carlsson



-- 
Torped Strategi och Kommunikation AB
Johan Carlsson
[EMAIL PROTECTED]

Mail:
Birkagatan 9
SE-113 36  Stockholm
Sweden

Visit:
Västmannagatan 67, Stockholm, Sweden

Phone +46-(0)8-32 31 23
Fax +46-(0)8-32 31 83
Mobil +46-(0)70-558 25 24
http://www.torped.se
http://www.easypublisher.com


___
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] __getattr__ and Acquisition

[Lennart Regebro]

From: "Andreas Kostyrka" <[EMAIL PROTECTED]>
> Well, where do you intenden your getattr to get the attribute from?

As I said, this is an example. This getattr part is supposed to be replaced
with whatever you do to get the attribute. Otehrwise it would be rather
useless, since it wouldn't do anything that isn't already done. :-)

> Difficult. Because __getattr__ does not have access to the acquisition
> chain.

Well, you fix that with __of__, which is what I was going to say, but
forgot. :-)
I won't venture in giving you any example code, though, but the PortalSkins
is one place to look. Also, depending of when you want the properties from
the transparent folder to be aqcuirable you might be able to wrap the object
by calling __of__ instead of overriding it.

Best Regards

Lennart Regebro, Torped
http://www.easypublisher.com/


___
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] __getattr__ and Acquisition

[Florent Guillaume]

Andreas Kostyrka  <[EMAIL PROTECTED]> wrote:
> Am Mon, 2002-09-23 um 11.12 schrieb Florent Guillaume:
> > Anoter way to do that is to play games with __of__.
> > Look at the implementation of the skins tool in CMF for an example.
> Doesn't help, as I do NOT know my container :(

Yes it does.
__of__ is non-intuitive but it can work.

> Basically __getattr__ when called does not know it's containment
> anymore. :(

You didn't look a the code I pointed to you. Look at CMFCore/Skinnable
to be precise (not everything is to be used of course).

* In __of__ you store the parent in a volatile attribute,
* in __getattr__ you lookup the volatile attribute

This works as long as your object is not used in several different
acquisition contexts.


Florent
-- 
Florent Guillaume, Nuxeo (Paris, France)
+33 1 40 33 79 87  http://nuxeo.com  mailto:[EMAIL PROTECTED]

___
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] __getattr__ and Acquisition

[Andreas Kostyrka]

Am Mon, 2002-09-23 um 11.12 schrieb Florent Guillaume:
> Anoter way to do that is to play games with __of__.
> Look at the implementation of the skins tool in CMF for an example.
Doesn't help, as I do NOT know my container :(

Basically __getattr__ when called does not know it's containment
anymore. :(

Andreas


___
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] __getattr__ and Acquisition

[Andreas Kostyrka]

Am Mon, 2002-09-23 um 13.10 schrieb Chris Withers:
> Andreas Kostyrka wrote:
> > The problem is, that __getattr__ does not have access to the acquisition
> > chain. 
> 
> I think it does, but I may be corrected.
Well, it's definitly not wrapped. I know because I had to work around
that. And it's definitly quite sick how I do this :)

> 
> Some things to check for:
> 
> 1. Do the classes of you object (and containing objects) inherit for 
> Acquisition.Implicit?
I inherit from OFS.Folder.Folder, this should be enough, wouldn't it?
Especially Acquisition works quite well in all other methods, just not
__getattr__.
> 
> 2. Are you getting hold of the object in such a way that it is acquisition wrapped?
Well, I'm not getting hold of anything. It's more like Zope is getting
hold of my objects to publish.

As I've solved my problem (well, it works, I understand the problem, and
I know the correct solution, but I shying away of hacking Acquisition.
It's easier (for me) to get my wrapper from the Python frame stack than
to patch Acquisition.c.)

Andreas


___
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] __getattr__ and Acquisition

[Andreas Kostyrka]

Am Mon, 2002-09-23 um 10.35 schrieb Lennart Regebro:
> From: "Andreas Kostyrka" <[EMAIL PROTECTED]>
> > Nope it is not. In a normal method you can access something acquired
> > like this:
> > self.acquired_value.
> 
> I often do just that. :-) I'm not 100% sure what you need to include for
> that to work, but I would expect that it is Aqcuisition.Implicit.
Well, Acquisition does not work in __getattr__. This seems trivially
because the "self" is unwrapped in the case of __getattr__, while it's
wrapped when called on a normal method.
> 
> > The problem is, that __getattr__ does not have access to the acquisition
> > chain.
> 
> Well, it does, but it typically causes infinite recursion if you aren't
Well, it would perhaps make sense for Acquisition to use the
equivalent of getattr(self.aq_explicit,name) instead of
getattr(aq_base(self),name)
This way you have no infinite recursion, but still can acquire things
explicitly with aq_acquire :)

> careful. Something like this might work (this is untested code, adapted from
> something that is a bit more complex that we are doing):
> 
> def __getattr__(self, name, marker=None):
> if not name.startswith('_') and not name.startswith('aq_'):
> if not name in self._v_ignore_attrib:
> subob = getattr(self,name,_marker)
Well, where do you intenden your getattr to get the attribute from? 
> self._v_ignore_attrib=[]
> # Return it in context of self, forgetting
> # its location and acting as if it were located
> # in self.
> return aq_base(subob)
> else:
> self._v_ignore_attrib.append(name)
> 
> raise AttributeError, name
> 
> 
> > Basically I want "Transparent Folders" which get their "transparent
> > values from the Acquisition path.
> 
> Aha. Well, I wouldn't call it trivial, but it is definitely doable.
Difficult. Because __getattr__ does not have access to the acquisition
chain. (Just looking at Acquisition.c makes my head go all jelly ;) )

1.) Change Acquisition to call getattr not on self but on an explicit
wrapper of self. see above. 
Problem: Compability with Zope? Should probably work. But perhaps there
are things that rely on self being the object and not an explicit
Wrapper.
Problem: The idea of patching Acquisition.c makes my head spin.
Problem: Not possible to fix it up as an Product -> needs a patch to
Zope.

2.) Fetch my a wrapped copy of self from the Python call stack.
Problem: It's an example of code that would be labelled "Do not copy
this style!"
Problem: Can break at the most curious moments.

3.) Store the wrapped self in some attribute during traversal.
Problem: This is plain wrong. It's not safe in a number of ways, ...
 (threads, multiple acquisition paths, etc.)

I've implemented solution 2) because 
- it's packable as a product
- I'm not sure a core change to Acquisition.c is something that has ANY
chance of getting into Zope.
- I'm not 100% sure that changing Acquisition.c will not break Zope in
some subtle ways.
- I'm already past the delivery deadline for my small application of
this. Hacking the Python stack seems something that I can predict much
better than any try to hack Acquisition.c :(

Andreas


___
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] __getattr__ and Acquisition

[Chris Withers]

Andreas Kostyrka wrote:
> The problem is, that __getattr__ does not have access to the acquisition
> chain. 

I think it does, but I may be corrected.

Some things to check for:

1. Do the classes of you object (and containing objects) inherit for 
Acquisition.Implicit?

2. Are you getting hold of the object in such a way that it is acquisition wrapped?

cheers,

Chris


___
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] __getattr__ and Acquisition

[Florent Guillaume]

Andreas Kostyrka  <[EMAIL PROTECTED]> wrote:
> Am Mon, 2002-09-23 um 00.18 schrieb Lennart Regebro:
> > From: "Andreas Kostyrka" <[EMAIL PROTECTED]>
> > > I've just discovered, that Acquisition does not work with __getattr__,
> > > right?
> > 
> > That depends on what you mean with "does not work". :-)
> > 
> > > (I assume that this is so because something like getattr(mybase,attr) is
> > > called during the acquisition process to prevent infinite recursion.)
> > > 
> > > Anyway to get around that? (To basically get a wrapped self from
> > > somewhere?)
> > 
> > That's what self usually is... :-)
> Nope it is not. In a normal method you can access something acquired
> like this:
> self.acquired_value.
> Even more, this works for __bobo_traverse__. It just works for the
> publishing not accessing my attributes later on during publication.
> 
> The problem is, that __getattr__ does not have access to the acquisition
> chain. Now I storing the "acquisition chain" in the object is not a
> sound proposition, because it is not thread safe. Worse the object might
> be accessed in some way that makes the acquisition chain not be updated.

Anoter way to do that is to play games with __of__.
Look at the implementation of the skins tool in CMF for an example.

Florent
-- 
Florent Guillaume, Nuxeo (Paris, France)
+33 1 40 33 79 87  http://nuxeo.com  mailto:[EMAIL PROTECTED]

___
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] __getattr__ and Acquisition

[Lennart Regebro]

From: "Andreas Kostyrka" <[EMAIL PROTECTED]>
> Nope it is not. In a normal method you can access something acquired
> like this:
> self.acquired_value.

I often do just that. :-) I'm not 100% sure what you need to include for
that to work, but I would expect that it is Aqcuisition.Implicit.

> The problem is, that __getattr__ does not have access to the acquisition
> chain.

Well, it does, but it typically causes infinite recursion if you aren't
careful. Something like this might work (this is untested code, adapted from
something that is a bit more complex that we are doing):

def __getattr__(self, name, marker=None):
if not name.startswith('_') and not name.startswith('aq_'):
if not name in self._v_ignore_attrib:
subob = getattr(self,name,_marker)
self._v_ignore_attrib=[]
# Return it in context of self, forgetting
# its location and acting as if it were located
# in self.
return aq_base(subob)
else:
self._v_ignore_attrib.append(name)

raise AttributeError, name


> Basically I want "Transparent Folders" which get their "transparent
> values from the Acquisition path.

Aha. Well, I wouldn't call it trivial, but it is definitely doable.

> Well, I just had an idea for an implementation:
> Third idea: I return some callable object the was generated specifically
> for the access from the __getattr__. This is than executed with
> Acquisition enabled, so it can try to get the real one, 
> Problem: What if the attribute does not exist? I do not thing that Zope
> reacts to well when instead of a AttributeError exception it gets some
> object that raises AttributeError when accessed, 
>
> Andreas
>
>


___
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] __getattr__ and Acquisition

[Andreas Kostyrka]

Am Mon, 2002-09-23 um 00.18 schrieb Lennart Regebro:
> From: "Andreas Kostyrka" <[EMAIL PROTECTED]>
> > I've just discovered, that Acquisition does not work with __getattr__,
> > right?
> 
> That depends on what you mean with "does not work". :-)
> 
> > (I assume that this is so because something like getattr(mybase,attr) is
> > called during the acquisition process to prevent infinite recursion.)
> > 
> > Anyway to get around that? (To basically get a wrapped self from
> > somewhere?)
> 
> That's what self usually is... :-)
Nope it is not. In a normal method you can access something acquired
like this:
self.acquired_value.
Even more, this works for __bobo_traverse__. It just works for the
publishing not accessing my attributes later on during publication.

The problem is, that __getattr__ does not have access to the acquisition
chain. Now I storing the "acquisition chain" in the object is not a
sound proposition, because it is not thread safe. Worse the object might
be accessed in some way that makes the acquisition chain not be updated.


> 
> I think you need to answer a couple of questions:
> 1. What is it you want to do?
> 2. How are you trying to do it?
> 3. What is happening when you try to do it?
It's actually trivial ;)
I want to acquire some things in __getattr__.
Basically I want to insert an additional access step like this:
1.) a.b.c.o -> o if o exists in c
2.) a.b.c.o -> Folder.o (where Folder is acquired from a.b.c) if it's 
   exist.
3.) a.b.c.o -> tries to acquire o from a.b.c.

Basically I want "Transparent Folders" which get their "transparent
values from the Acquisition path.

Well, I just had an idea for an implementation:
Third idea: I return some callable object the was generated specifically
for the access from the __getattr__. This is than executed with
Acquisition enabled, so it can try to get the real one, 
Problem: What if the attribute does not exist? I do not thing that Zope
reacts to well when instead of a AttributeError exception it gets some
object that raises AttributeError when accessed, 

Andreas


___
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] __getattr__ and Acquisition

[Lennart Regebro]

From: "Andreas Kostyrka" <[EMAIL PROTECTED]>
> I've just discovered, that Acquisition does not work with __getattr__,
> right?

That depends on what you mean with "does not work". :-)

> (I assume that this is so because something like getattr(mybase,attr) is
> called during the acquisition process to prevent infinite recursion.)
> 
> Anyway to get around that? (To basically get a wrapped self from
> somewhere?)

That's what self usually is... :-)

I think you need to answer a couple of questions:
1. What is it you want to do?
2. How are you trying to do it?
3. What is happening when you try to do it?

It's hard to give solutions when you don't know the problem. :-)

Best Regards

Lennart Regebro
http://www.easypublisher.com/

___
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] __getattr__ and Acquisition

[Andreas Kostyrka]

Hi!

I've just discovered, that Acquisition does not work with __getattr__,
right?

(I assume that this is so because something like getattr(mybase,attr) is
called during the acquisition process to prevent infinite recursion.)

Anyway to get around that? (To basically get a wrapped self from
somewhere?)

I see two "solutions":
-) I let some method (like pretraversal) acquire my object and store a
reference in my object. This might work if the object is changed seldom
and the method is called regularly enough, ...
-) I walk the frame stack and extract the wrapped self from it. Not
really nice, but then Zope does a number of black magic things :)

Andreas



___
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 )