Re: [Zope3-dev] Re: TALES PathExpr doesn't call old style classes
Dieter Maurer wrote: > Philipp von Weitershausen wrote at 2006-5-24 18:16 +0200: >> ... >> Yup. We could think about this for some future release cycle, though. >> I'd very much be in favour of making nocall: the default and introduce >> something like call:. Then sniffing for callableness wouldn't be necessary. > > You are aware how many templates you would break? Of course, we'd have to introduce it in a way that wouldn't break all the existing templates at once. There are numerous possibilities to do that, all of which can be discussed in due time when this becomes an issue. Right now my focus is getting Zope 2.10 in a beta status. Philipp ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Re: TALES PathExpr doesn't call old style classes
Philipp von Weitershausen wrote at 2006-5-24 18:16 +0200: > ... >Yup. We could think about this for some future release cycle, though. >I'd very much be in favour of making nocall: the default and introduce >something like call:. Then sniffing for callableness wouldn't be necessary. You are aware how many templates you would break? -- Dieter ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
RE: [Zope3-dev] Re: TALES PathExpr doesn't call old style classes
Hi Philipp, Florent [...] > > There *is* a way to check whether the error resulted from > the current > > frame or a lower frame. Introspections like these have the > tendency to > > be or become hacks, but then again, we use frame > inspections in other > > places, too. > > Yes, I was about to suggest using the standard PJE trick used > elsewhere in Zope 3 (to check for deep ImportErrors), namely: > > try: >ob() > except (TypeError, AttributeError): >if sys.exce_info()[2].tb_next is not None: > raise ># here we know the exception was not "deep" ># so the object isn't callable Good point Regards Roger Ineichen > Florent ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
RE: [Zope3-dev] Re: TALES PathExpr doesn't call old style classes
Hi Philipp [...] > > Are there really usecases where something can go wrong if > we use the > > proposed PEP? > > Calling something that may or may not be callable can yield > at least two different exceptions: TypeError or > AttributeError (on __call__). That means we'd already have to > catch two pretty common exceptions and therefore "eat" > exceptions that might occur inside the called routine. [...] You are right, I missed that. Regards Roger Ineichen > Philipp > ___ > Zope3-dev mailing list > Zope3-dev@zope.org > Unsub: > http://mail.zope.org/mailman/options/zope3-dev/dev%40projekt01.ch > > ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Re: TALES PathExpr doesn't call old style classes
On 25 May 2006, at 00:38, Philipp von Weitershausen wrote: just to get this straight: I'm not going to discuss in this thread what changes we might do to TALES in the future. I'm strictly concerned about this release cycle, not a future one. That doesn't I won't be interested in discussing these matters in the future... Are there really usecases where something can go wrong if we use the proposed PEP? Calling something that may or may not be callable can yield at least two different exceptions: TypeError or AttributeError (on __call__). That means we'd already have to catch two pretty common exceptions and therefore "eat" exceptions that might occur inside the called routine. This would make debugging very hard. It also isn't mentioned in the spec currently that TypeErrors and AttributeErrors would be eaten silently, so we'd really be changing the behaviour. There *is* a way to check whether the error resulted from the current frame or a lower frame. Introspections like these have the tendency to be or become hacks, but then again, we use frame inspections in other places, too. Yes, I was about to suggest using the standard PJE trick used elsewhere in Zope 3 (to check for deep ImportErrors), namely: try: ob() except (TypeError, AttributeError): if sys.exce_info()[2].tb_next is not None: raise # here we know the exception was not "deep" # so the object isn't callable Florent If no one objects, I will fix Zope 3's PathExpr to check for a __call__ method using getattr() (as documented in the collector issue, http://www.zope.org/Collectors/Zope3-dev/635) and additionally check whether the object might be an old style class, as suggested by Florent. We will have to result to different measures in Zope 2 anyways, for BBB reasons. Philipp -- Florent Guillaume, Nuxeo (Paris, France) Director of R&D +33 1 40 33 71 59 http://nuxeo.com [EMAIL PROTECTED] ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Re: TALES PathExpr doesn't call old style classes
Hi, just to get this straight: I'm not going to discuss in this thread what changes we might do to TALES in the future. I'm strictly concerned about this release cycle, not a future one. That doesn't I won't be interested in discussing these matters in the future... > Are there really usecases where something can go wrong > if we use the proposed PEP? Calling something that may or may not be callable can yield at least two different exceptions: TypeError or AttributeError (on __call__). That means we'd already have to catch two pretty common exceptions and therefore "eat" exceptions that might occur inside the called routine. This would make debugging very hard. It also isn't mentioned in the spec currently that TypeErrors and AttributeErrors would be eaten silently, so we'd really be changing the behaviour. There *is* a way to check whether the error resulted from the current frame or a lower frame. Introspections like these have the tendency to be or become hacks, but then again, we use frame inspections in other places, too. If no one objects, I will fix Zope 3's PathExpr to check for a __call__ method using getattr() (as documented in the collector issue, http://www.zope.org/Collectors/Zope3-dev/635) and additionally check whether the object might be an old style class, as suggested by Florent. We will have to result to different measures in Zope 2 anyways, for BBB reasons. Philipp ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
RE: [Zope3-dev] Re: TALES PathExpr doesn't call old style classes
Hi Philipp, Florent [...] > >> In particular, I'm looking for comments on problem #2. > > > > Well, following the mantra of "explicit is better than > implicit" I'd > > rather have ZPT never call things magically, but I know > that's not the > > problem at hand and it poses backward compat problems anyway... Too > > bad though. I don't agree if I understand this correct. We have attributes or methods which we access from a page template via TAL. right? I don't think we can speak about implicit or explicit. The problem is, that we have one accessor method and two different accessible implementations. If I access a foo() method from TAL it is not implicit if I don't call them, it's more a wrong concept for accessing a method. I whould preferre if both use case get handled by default correct, doesn't matter if I access a attribute or a method. Why not use the proposed PEP3000? And also additional nocall: and call: accessor in a page template. This means existing implementation will not break and everybody how likes to use explicit accessors like call: or nocall: can use it explicit. I think this whould make everybody happy. Or not? I think the nocall: method in TAL is only useful if we like to get a function pointer where we call different times in the template. Or did I miss something? Are there really usecases where something can go wrong if we use the proposed PEP? Regards Roger Ineichen ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] Re: TALES PathExpr doesn't call old style classes
Florent Guillaume wrote: > Philipp von Weitershausen wrote: >> Hi there, >> >> I've filed an issue in the collector outlining a problem with old style >> classes and TALES traversal: http://www.zope.org/Collectors/Zope3-dev/635 >> >> In particular, I'm looking for comments on problem #2. > > Well, following the mantra of "explicit is better than implicit" I'd > rather have ZPT never call things magically, but I know that's not the > problem at hand and it poses backward compat problems anyway... Too bad > though. Yup. We could think about this for some future release cycle, though. I'd very much be in favour of making nocall: the default and introduce something like call:. Then sniffing for callableness wouldn't be necessary. > For #2 I'd just do a check that type(C) is classobj, even though this > doesn't take care of proxied old-style classes (who uses those anyway?). I guess that'd be ok. > BTW your comment in the patch about getattr(ob, '__call__', _marker) > triggering acquisition isn't really true, as attributes starting with > '_' are never looked up by an implicit acquisition wrapper (although you > can still ask for them explicitely by using aq_acquire). Ah good, to know. I added this remark and your suggestion above to the issue transcript. I will commit a patch later this week. Philipp ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] Re: TALES PathExpr doesn't call old style classes
Philipp von Weitershausen wrote: Hi there, I've filed an issue in the collector outlining a problem with old style classes and TALES traversal: http://www.zope.org/Collectors/Zope3-dev/635 In particular, I'm looking for comments on problem #2. Well, following the mantra of "explicit is better than implicit" I'd rather have ZPT never call things magically, but I know that's not the problem at hand and it poses backward compat problems anyway... Too bad though. For #2 I'd just do a check that type(C) is classobj, even though this doesn't take care of proxied old-style classes (who uses those anyway?). BTW your comment in the patch about getattr(ob, '__call__', _marker) triggering acquisition isn't really true, as attributes starting with '_' are never looked up by an implicit acquisition wrapper (although you can still ask for them explicitely by using aq_acquire). Florent -- Florent Guillaume, Nuxeo (Paris, France) Director of R&D +33 1 40 33 71 59 http://nuxeo.com [EMAIL PROTECTED] ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
