[SciPy-Dev] cKDTree

Pauli Virtanen pav at iki.fi
Tue Sep 6 16:40:35 EDT 2016


Tue, 06 Sep 2016 20:23:05 +0200, Sylvain Corlay kirjoitti:
[clip]
> This sort of raises the question of the scope of scipy. Should scipy
> go through the same sort of "big split" as Jupyter or more à la d3js? Is
> amount of specialized knowledge required to understand a methods part of
> what defines the line of division in what should be or not be in scipy?

I'm not sure a "big split" will help with defining the scope --- only 
changing the name of "scipy.spatial" to "scikit-spatial" will likely not 
help in deciding what its scope is. Splitting may help with speeding up 
the release cycle, but if the team stays the same, it sounds likely to 
multiply the amount of release work. Rebuild times etc. development 
convenience are probably not a reason to split, as I think it's fast 
enough in practice currently.

The general decision rule to accept has so far been generally conditional 
on, (i) the method is applicable in many fields and "generally agreed" to 
be useful, (ii) fits the topic of the subpackage, and does not require 
extensive support frameworks to operate, (iii) the implementation looks 
sound and unlikely to need much tweaking in the future, and (iv) someone 
wants to do it.

I don't remember being involved with DE, and can't immediately comment on 
how the PCA trees look here.

I think the original suggestion of scikits being something that will 
eventually, after maturing, end up in Scipy has not very generally been 
the case in practice. To my memory, many of the recent new features were 
written specifically for Scipy from the beginning.  (OTOH, I admit I did 
not go and look through merged pull requests with this eye, so maybe the 
this claim is not accurate.)

I also don't really feel that the implied idea of Scipy as a "repository 
of algorithms" where you hand off code, developed in some other project 
on PyPi, for someone else to maintain is workable in practice --- that 
doesn't sound like a living open source project. I would rather mentally 
substitute "scipy.interpolate" with "scikit-interpolate" and work 
accordingly to that picture.

-- 
Pauli Virtanen




More information about the SciPy-Dev mailing list