[SciPy-Dev] removing pure python KDTree implementation

[Julian Taylor]

On 22.02.2016 22:18, Ralf Gommers wrote:
> 
> 
> On Sun, Feb 21, 2016 at 2:41 PM, Sturla Molden <sturla.molden at gmail.com
> <mailto:sturla.molden at gmail.com>> wrote:
> 
>     Ralf Gommers <ralf.gommers at gmail.com
>     <mailto:ralf.gommers at gmail.com>> wrote:
>     > Hi all,
>     >
>     > For a long time we've had both a Python (KDTree) and a Cython/C++ (cKDTree)
>     > version of a k-d tree structure in scipy.spatial. The cKDTree version
>     > reached feature-parity with KDTree in 0.12.0, and new features are being
>     > added regularly now. So keeping the orders of magnitude slower pure Python
>     > version seems to be a bit pointless - only adds to a maintenance burden and
>     > to giving users an unnecessary choice to make.
>     >
>     > So proposal: remove the pure Python code and make KDTree an alias for
>     > cKDTree. This can be done straight away.
>     >
>     > For the future it may also be desirable to get rid of the duplicate name.
>     > The issue then is which one to keep. KDTree is nicer, but it would require
>     > users who have picked the fast version now to change their code. So maybe
>     > just deprecate one in documentation, but keep both names working?
> 
> 
>     What about this?
> 
>     1. make KDTree an alias for cKDTree
>     2. make KDTreeNode an alias for cKDTreeNode
>     3. keep all names working
>     4. only have KDTree and KDTreeNode in the documentation
>     5. keep kdtree.py for the test suite, but do not export its contents
> 
> 
> That sounds good to me. Keeping the Python version as a fancy test class
> may be useful.
> 
> The only thing that we should probably provide is a robust version
> comparator (anyway a good idea), so users can write this in a robust way:
> 
>      if scipy_version >= (0, 18, 0):
>          KDTree()
>      else:
>          cKDTree()
> 
>  Ralf
> 

There is numpy.lib.NumpyVersion or scipy._lib._version.NumpyVersion
which should work (and also written by you ;) ).

Not sure why that is in private namespace in scipy, imo it makes sense
to have that as a public alias like many other numpy functions in scipy.