[SciPy-Dev] cKDTree

[Ralf Gommers]

On Wed, Sep 7, 2016 at 11:19 AM, Pauli Virtanen <pav at iki.fi> wrote:

> 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?
>
> To write a bit more on this, although I think it's difficult to give hard
> rules on what "generally useful and generally agreed to work" means, I
> would perhaps weigh the following against each other:
>
> - Is the method used/useful in different domains in practice?
>   How much domain-specific background knowledge is needed to use it
>   properly?
>
> - Consider the stuff already in the module.  Is what you are adding
>   an omission?  Does it solve a problem that you'd expect the module
>   be able to solve?  Does it supplement an existing feature in
>   a significant way?
>
> - Consider the equivalence class of similar methods / features usually
>   expected. Among them, what would in principle be the minimal set so
>   that there's not a glaring omission in the offered features remaining?
>   How much stuff would that be? Does including a representative one of
>   them cover most use cases? Would it in principle sound reasonable to
>   include everything from the minimal set in the module?
>
> - Is what you are adding something that is well understood in the
>   literature? If not, how sure are you that it will turn out well?
>   Does the method perform well compared to other similar ones?
>
> - Note that the twice-a-year release cycle and backward-compat
>   policy makes correcting things later on more difficult.
>
> The scopes of the submodules also vary, so it's probably best to consider
> each as if a separate project --- "numerical evaluation of special
> functions" is relatively well-defined, but "commonly needed optimization
> algorithms" less so.
>
> On a meta-level, it's probably also bad to be too restrictive on the
> scope, as telling people to go away can result to just that.
>

Thanks Pauli, this and your other mail are the best summary yet of how to
judge suitability for inclusion. I propose to stick this almost verbatim in
the developer docs.

Ralf
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/scipy-dev/attachments/20160908/7d53013f/attachment.html>