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
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
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 attr
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
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
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
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 wa
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
__
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
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 "sel
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 containe
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 b
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.
> > D
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
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 volatil
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
>
>Th
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 anyt
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_
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
anymor
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 d
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
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
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"
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
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
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 proces
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
somew
27 matches
Mail list logo
