Eric Snow added the comment: > 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. ---------- _______________________________________ 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
