Re: Changes to trunk/scipy/optimize

2010/2/9 Dmitrey <tmp50 <at> ukr.net>:
> I had asked it 2 days ago before today's commit
> http://permalink.gmane.org/gmane.comp.python.scientific.devel/12740
> why couldn't you answer earlier?

Thanks for raising the issue to the list.  Sorry, I missed your
original email and I am sure Stefan must have missed it as well.
Please don't take this discussion as in any way an attempt to
discourage people from using OpenOpt or suggesting you did anything
wrong.  I know that OpenOpt is extremely useful and you've done a
great job developing it.

> as for mention scikits.openopt, it was allowed that time I had asked for it
> (about 2 years ago).

Just to be clear, I think Stefan was asking a more general question
that arose due to this specific instance.  The OpenOpt situation is a
bit unique since it was originally a Google SoC project for SciPy, but
after funding ran out became a successful stand-alone project of its
own.

Now the question is where is the best place for us to reference
external, but relevant and useful Python projects.  My personal
feeling is that it shouldn't be in the 'see also' section of our
docstrings, but we don't have any official policy on that yet.  So we
need to have a general discussion about what the general policy should
be.

Personally I would say that the primary place to point to external
packages is in the topical software section of website.  For instance,
OpenOpt is pointed to here:
http://www.scipy.org/Topical_Software#head-d21a11d2d173826993e03eb937fac7e6347e6d5f
I also think it would be fine to occasionally use external packages in
the tutorials if deemed useful.  But, in general, I would expect
external packages to have their own tutorials.  I would prefer to
limit the docstrings to just our core projects (numpy and scipy for
certain and perhaps the scikits as well).  If we don't limit the
docstrings in this way, I can see us either 1) getting in the
situation where it isn't clear how much more we should add to the
docstrings for the sake of completeness or 2) inadvertently getting
into political battles by appearing to favor certain external projects
while not mentioning others.

I am very interested in hearing what everyone else thinks about this
issue.  However, I think it would be most useful to discuss this in
general, rather than with a focus on openopt.  So if we decide not to
reference external packages in scipy and it turns out that we
reference several others in addition to openopt, then we should apply
the same standard to all the cases.

Best,
Jarrod