I want to address the four main points of criticism in fixing this issue, just in case it's not clear why I think those lines of thought are wrong:

#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".

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

The problem with this argument is that it's the same argument people bring up to remove the `callable` builtin. The problem is that you wouldn't use `callable` at all if you can just try/call/except. So this argument is not pertinent to the problem at hand (`callable` doing incomplete checks).

#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? 

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?

> py -3 -mtimeit -s "def foo(): pass" "foo.__call__"
10000000 loops, best of 3: 0.0585 usec per loop

> py -3 -mtimeit -s "def foo(): pass" "callable(foo)"
10000000 loops, best of 3: 0.0392 usec per loop

Is this a significant margin? Also, I'm pretty sure those numbers can be improved.

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

#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).

Were do we draw the line here? 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?

The problem with this argument is that it attacks a different problem, that's just being made more visible if and when this problem of `callable` is fixed.

Lets consider this strawman here: if a an user writes code like this:

try:
    do important stuff
except:
    pass # have fun debugging, haha

who's at fault here? Is it the user that wrote that debugging black hole or is it python for letting the user do things like that? I don't think it's reasonable for Python to prevent exception masking bugs if the user was brave enough to write a descriptor.