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 [email protected] Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
