I understand Ionel's point, and it is indeed 'callable' that is the outlier here.  It only looks for the *existence* of the attribute, rather than actually retrieving it through the descriptor protocol (and therefore getting the AttributeError from the property).  Protocols like iter, on the other hand, actually use the attribute, and therefore do access it via the descriptor protocol, and properties therefore act like one would naively expect them to.  

That doesn't mean we should definitely change callable, but it does mean the idea isn't obviously wrong.  IMO it is indeed callable that has the surprising behavior here.  (Note: I did not think that at first, but I do after reading the iter discussion.  (NB: in general, __iter__ should *not* return self; that's a bug waiting to happen.))  But, callable is also...not exactly Pythonic at its core, as evidenced by Guido's desire to get rid of it.  So the fact that it is in some sense buggy or at least surprising is perhaps something that we just live with because of that.

IMO, code that depends on a __call__ property is a bit suspect anyway.  Something should be callable or not, not conditionally callable.  If a program wants things to be conditionally callable, the program can establish its own protocol for that.  (The same applies to __iter__, but there's no reason to intentionally break the fact that it does work, since it just falls out of how the language works.)

So I guess my feeling is...callable is buggy, but callable is a buggy API :)  So I'm 0 on this issue (not even +0 or -0).