Ionel Cristian Mărieș added the comment:
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.
----------
_______________________________________
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/issue23990>
_______________________________________
_______________________________________________
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
