You can clone with
HTTPS or Subversion.
We have been relying on KDTree for distance based queries up to now. In the past two months, there have been major updates to the cKDTree in scipy.spatial so that the api matches that of KDTree. I started a branch to explore the issues in using cKDTree in place of KDTree. I'm finding significant speedups along the lines of those reported here. There are some differences in the results for some of our tests and I think this is due to the way ties might be broken between the two implementations. Additionally, the sparse.distance_matrix of the cKDTree returns squared distances, whereas the old one returns distances and this also induces some failures.
So I think we should move to cKDTree in 1.7 (too many issues to fix for 1.6) and add some deprecation warnings in cases where a user has an older version of scipy (<0.12) where the cKDTree implementation may have been missing some of the methods of KDTree. We could fall back to KDTree in those cases, but this will make some doc and unit tests fail. We could do some conditional testing in these cases during the deprecation period, but this increases the dev burden so moving to cKDTree in say 1.8 while dropping support for KDTree then would seem the way to go.
This is now being dealt with in #460