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
changes we might do to TALES in the future. I'm strictly concerned
this release cycle, not a future one. That doesn't I won't be
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
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
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
Yes, I was about to suggest using the standard PJE trick used
elsewhere in Zope 3 (to check for deep ImportErrors), namely:
except (TypeError, AttributeError):
if sys.exce_info().tb_next is not None:
# here we know the exception was not "deep"
# so the object isn't callable
If no one objects, I will fix Zope 3's PathExpr to check for a
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
We will have to result to different measures in Zope 2 anyways, for
Florent Guillaume, Nuxeo (Paris, France) Director of R&D
+33 1 40 33 71 59 http://nuxeo.com [EMAIL PROTECTED]
Zope3-dev mailing list