"Alex Martelli" <[EMAIL PROTECTED]> wrote: > > On 7/17/06, Andrew Koenig <[EMAIL PROTECTED]> wrote: > > I note in PEP 3000 the proposal to remove callable(), with the comment "just > > call the object and catch the exception." > > > > I think that's a bad idea, because it takes away the ability to separate the > > callability test from the first call. As a simple example, suppose you're > > writing a function that you expect to be given a function as one of its > > arguments: > > > > def foo(bar, fun): > > assert callable(fun) > > # ... > > > > It might be that foo doesn't actually call fun until much later. > > Nevertheless, from a testing viewpoint, it would be better to detect the > > error immediately of passing something that can't be called. > > > > If you didn't have callable, how would you write this example? > > I might equivalently hasattr(type(fun), '__call__') [[net of oldstyle > classes, which won't be around in py3k anyway:-)]] and it would be > just as feeble -- essentially because when the time comes to CALL fun, > it will be called with specific signature[s], not "in a void".
I believe that callable as it stands is useful for what it was intended to do; tell you if something is callable. Whether or not a function is callable with a specific set of arguments as you suggest, would be useful, but not necessary in the cases that Andrew and others have been talking about. Also note that specifying and/or verifying call signatures is its own PEP. I personally believe that callable should stay as-is, and if signature verification is going to be done, it should probably have its own builtin (as code that was using callable(foo) before could break with changed semantics, and such breakage, I believe, would be gratuitous). - Josiah _______________________________________________ Python-3000 mailing list Python-3000@python.org http://mail.python.org/mailman/listinfo/python-3000 Unsubscribe: http://mail.python.org/mailman/options/python-3000/archive%40mail-archive.com
