Guido van Rossum <guido <at> python.org> writes: > > 1) Getting rid of 'callable'. > > > > The reccomended replacement is "just call the object and catch the resulting > > exception", but I can think of a lot of situations where that wouldn't be > > appropriate. For example, what if you want to know if something is > > callable, but you don't want to call it just yet? > > This has already been shot down by others (if you still disagree, too > bad for you, you're wasting your time). Let me just add that knowing > it is callable isn't sufficient to ensure that calling it with a > particular signature won't raise an exception. We could add something > much more useful once we have signature checking in place; but it > won't be called "callable" and it will likely have false negatives (if > the signature info is unavailable) rather than false positives (like > current callable()). > > > What if you intend on calling something 1000 times, and you'd like to > > know if its callable once, instead of catching the exception 1000 times? > > You could catch the exception only once, and then you'd disable the > bad callback -- if you cared at all. More likely you'd just let the > user figure it out from the first error and not worry about the rest.
All right, I'll desist. Not because I'm convinced, but because I realize that the existing behavior of "callable" isn't really what I want anyway. What I really want is to be able to answer the question: "Is 'x' an object that conforms to the naive, everyday concept of a function?" This is distinct from the existing callable, which attempts to answer the question: "If I attempt to call 'x', will I get an error?" How about instead of 'callable', an "isFunction' test to go along with 'isSequence' and 'isMapping'. (You aren't getting rid of those - I hope...?) My meta-concern here is this: One of the things I like about Python is that I am free to engage in other forms of program organization than just OOP. I realize that we all were taught the rules of OOP in comp sci 101 (well, ok, OOP was invented after I learned programming, but still...), but there are a lot of interesting alternatives - aspect-oriented programming, logic programming, expert systems, etc. Yet, I feel like in this case I'm being told that my testing of the type of an object is "bad style" because it's non-OOP. While there may be valid criticisms of this technique, this particular criticism seems falsely reductionist. (Also, I think that using exceptions as general flow-control constructs is a bigger style wart than type testing - but I've already resigned myself to the fact that the Python community doesn't agree with me on this point either. :) > You obviously weren't here when this was discussed. Having it be a > function, always, is useful in many ways, several of which can be > summed up as "future transformations". E.g. turn all print statements > into log calls. This is much easier when they are already calls. Also, > the various syntactic quirks (significant trailing comma, weird >> > syntax) require time to learn and to explain. Actually, I did read all those discussions, but I changed my mind :) I'm not sure that I buy the 'time to learn and explain' argument. If we take that to its logical extreme, then we should be using Lisp, since there's only a single syntactical constructs to learn and explain. To my mind, the purpose of syntax is to act as a scaffolding to hold ideas in place in a way that allows us to easily recognize them. To that extent, a syntax should neither be too simple or too complicated, just as an alphabet should neither be too large nor too small. As far as re-routing print goes, what's the difference between that and simply redirecting stdout? (Or providing some other hook.) -- Talin _______________________________________________ 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
