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:

except (TypeError, AttributeError):
  if sys.exce_info()[2].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 __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


Florent Guillaume, Nuxeo (Paris, France)   Director of R&D
+33 1 40 33 71 59   http://nuxeo.com   [EMAIL PROTECTED]

Zope3-dev mailing list
Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com

Reply via email to