This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Author ionelmc
Recipients Claudiu.Popa, belopolsky, christian.heimes, eric.snow, ethan.furman, ionelmc, jedwards, llllllllll, r.david.murray, rhettinger, steven.daprano, terry.reedy
Date 2015-04-19.22:33:20
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <>
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:

    do important stuff
    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.
Date User Action Args
2015-04-19 22:33:20ionelmcsetrecipients: + ionelmc, rhettinger, terry.reedy, belopolsky, christian.heimes, steven.daprano, r.david.murray, Claudiu.Popa, ethan.furman, eric.snow, llllllllll, jedwards
2015-04-19 22:33:20ionelmcsetmessageid: <>
2015-04-19 22:33:20ionelmclinkissue23990 messages
2015-04-19 22:33:20ionelmccreate