[Python-3000] callable()

[Josiah Carlson]

Nick Coghlan <ncoghlan at gmail.com> wrote:
> Use cases for a "may be hashable" pretest are much weaker (and typically 
> hypothetical), but there are cases where it makes a certain amount of sense. 
> For example, if you have a set-based fast path if all the objects being 
> handled are hashable, and a list-based slow path if one or more aren't 
> hashable, and the hashes themselves may be expensive to calculate (e.g. some 
> of the objects may be large strings) then it may make sense to perform a 
> precheck to ensure that all of the objects are at least *potentially* hashable 
> before you try to put any of them into a set.

Why doesn't it make sense to assume the "fast path" and on failure
switch to the "slow path"? (assuming the "fast path" wins on big-O or
even a nontrivial constant factor) Such a method can only, in the worst
case, be twice as slow as the 'full knowledge zero overhead are all
items hashable?' check.  But since the evaluation went to the "slow path",
the "fast path" overhead may be inconsequential.  However, hashability
checks on the "fast path" may not be inconsequential in relation to the
normal running time of the "fast path".

In that sense, hashable() is a waste of time, as it slows down the "fast
path" by up to a constant, without improving the "slow path" by anything
more than a constant.  But those constants are different, relatively
large in the case of the "fast path", relatively small in the case of
the "slow path".

Hashable is getting a big, fat, -1 from me.

On the other hand, I'm a full supporter of callable(), and don't much
care about iterable(), but leaning towards -1.

 - Josiah