> Ionel Cristian Mărieș added the comment:
> #1. "It's specified/documented, therefore it's intended"
>
> The first thing a maintainer does is check the docs. This is a sensible thing to do - as you cannot have all the details in your hear. The main question at that point: "is it really like that?".
>
> However, it's easy to miss the fact that the documentation explains an implementation issue (`callable` is not really reliable, blablabla), and not the intent of `callable`.
>
> I mean, the name is pretty clear on what it's supposed to do: "is the object callable or not?" - simple as that. If the intent of `callable` is being unreliable then maybe we should just rename it to `maybe_callable` or `unreliable_callable`, or maybe even "crappy_callable_we_dont_want_to_fix".

"callable" refers to the compatibility of the object with the call
syntax - simple as that.  The call syntax is turned into a special
lookup for "__call__" that explicitly skips lookup on the instance (in
CPython it is a call to _PyObject_LookupSpecial) and then a call on
the resulting value.

You are correct that callable does not do the descriptor part of that
lookup.  However, that is consistent across Python and has been this
way for a long time (so there are backward compatibility concerns that
cannot be ignored).

>
> #2. "But the call could fail anyway, so what's the point of fixing this?"

You are correct that the availability of __call__ is the only relevant
issue here.

>
> #3. "But it's going to be too slow!"
>
> I don't want to be mean here, but this is just FUD. Lets measure this first. Is there really a measurable and significant performance impact on major applications?

It's not just applications.  Grep for "PyCallable_Check" in the
CPython code base.

>
> Does the argument even make sense in theory? A function call is pretty expensive in python, a mere attribute lookup wouldn't increase the cost by an order of magnitude (like 10x), would it?

A "mere attribute lookup" involves invoking the descriptor protocol.
This would add a discernible performance impact and the possibility of
running arbitrary code for the sake of a rare corner case.  The
overall impact would be small, especially considering the use of
PyCallable_Check in the CPython code base, but do not assume it would
be insignificant.

> Python 3 regressed performance in various aspects (and improved other things, of course), why would this be a roadblock now?

My apology for being so blunt, but that's a terrible rationale!  Let's
make it better not worse.

>
> #4. "It's too tricky, and I had a bad time with pickle one time ago", or: Exception masking issues
>
> This is certainly a problem, but it's not a new problem. There are already dozens of places where AttributeError is masked into something else (like a TypeError, or just a different result).

It not a problem currently for callable.  It is one you are proposing
to introduce.  It is one which current users of callable don't have to
worry about.

>
> Were do we draw the line here?

We don't add to the problem.  Instead, we work to decrease it.

> Do we want to eventually get rid of all exception masking in an eventual Python 4.0 - what's the overarching goal here? Or is this just one of the many quirks of Python?
>
> What's worse - a quirk or a inconsistent quirk?

What's the quirk here?  I'd argue that the quirk is that special
method lookup (_PyObject_LookupSpecial) doesn't turn AttributeError
from a getter into RuntimeError.