[Python-3000] PEP 3100 Comments

[Talin]

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