[SciPy-Dev] removing pure python KDTree implementation

[Todd]

On Feb 22, 2016 10:18 PM, "Ralf Gommers" <ralf.gommers at gmail.com> wrote:
>
>
>
> On Sun, Feb 21, 2016 at 2:41 PM, Sturla Molden <sturla.molden at gmail.com>
wrote:
>>
>> Ralf Gommers <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
>

If people want backwards compatibility, can't they just continue to use the
cKDTree name?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/scipy-dev/attachments/20160225/993bed55/attachment.html>