[ZODB-Dev] Persistent-derived class instances always callable

[Shane Hathaway]

On Fri, 17 Oct 2003, Tim Peters wrote:
> I'm unclear why it's needed -- in over a decade of programming Python, the
> first time I used callable() was when typing the last reply <wink>.

Zope uses callable() heavily.  No, I take it back--it used to use
callable(), until we discovered it does not work at all with
ExtensionClasses.  Zope now uses its own implementation of callable().

Consider that there are two kinds of weakref proxies: callable and
non-callable.  AFAIK the only reason for this is to work around the
expectations of callable().  Does this mean everyone who writes proxies
(such as the acquisition wrappers in ExtensionClass and Zope 3's context
wrappers) needs to follow this same pattern?

If Python someday adds builtins like iterable() and hashable() in addition
to callable(), and they only look at slots, does that mean there will be
*eight* weakref proxy types?

> If it is needed, and you don't want to fight a losing battle with the
> language design, then it's going to be a user-land convention.  For example,
> create an ICallable interface, and use the interface machinery to declare
> with objects think they're callable, then check an object to see whether it
> implements ICallable.

I agree.  My position is that callable() ought to be reliable or it ought
to be deprecated.  Zope 2 wouldn't be hurt by deprecating it, and ideally
Zope 3 won't even need it.  But right now it seems like Python can't
decide whether callable() is good or not, and it's leading to workarounds
just to satisfy the needs of someone neither of us knows.

Shane