[SciPy-User] Pylab - standard packages

josef.pktd@gmai... josef.pktd@gmai...
Fri Sep 21 06:53:40 CDT 2012


On Fri, Sep 21, 2012 at 6:52 AM, Thomas Kluyver <takowl@gmail.com> wrote:
> Thanks Fernando, you've coherently explained what I was trying to say
> about why we can and should take sides.
>
> On 21 September 2012 02:19, Fernando Perez <fperez.net@gmail.com> wrote:
>> I think this has been danced around but not really discussed with
>> enough precision: a clear dividing line should be drawn between "needs
>> a compiler" and not.  Because the complexities of getting a compiler
>> off the ground in some platform are not trivial, and the details
>> change over time, I think that the 'base level' should consist of very
>> broadly applicable tools that do *not* need a C compiler to be
>> installed for working.  The 2nd level would require a C compiler, thus
>> putting Cython (and in the future numba or similar tools if llvm
>> becomes more widely accepted as the path forward) squarely in that
>> camp.
>
> I like this way of drawing a clear, objective distinction between
> levels. We would still need to work out how to present the different
> levels to users, but that's something I think we could resolve.
>
>> I've had for a while this basic 'layering' of the ecosystem in my mind
>> that I use as a starting point for these conversations:
>>
>> https://speakerdeck.com/u/fperez/p/1204-biofrontiers-boulder?slide=21
>>
>> I think if you take all that minus Cython and Mayavi (for dependency
>> complexity reasons, VTK is a non-triival beast to deal with too), the
>> rest is a pretty decent core that covers a lot of what a good fraction
>> of undergraduate courses in the sciences would broadly need.
>
> To save people a click, Fernando's tiers look like this:
>
> Python
> ---
> Numpy
> ---
> IPython, Scipy, Matplotlib, SymPy
> ---
> pandas, StatsModels, scikits-learn, scikits-image, scikits-image,
> PyTables, NetworkX
>
> That seems like a vision of a much more comprehensive environment than
> we had been discussing, but all those packages are familiar names at
> Scipy conferences, and it would inarguably make a much more capable
> environment out of the box than just numpy+scipy+mpl. If we were to
> use that as a starting point, would anyone like to argue against
> including some of those packages?
>
> Almar has already spoken against specifying an interface. I'm actually
> leaning the other way, although I accept that I could be biased by my
> role in IPython. For introductory tutorials, I think it would be very
> valuable to have a common interface, so we can describe, say, what to
> press to run some code. Otherwise, users would be put off by having to
> try to apply a generalised tutorial to their particular environment,
> and interpret screenshots that don't match what they see. In
> particular, the IPython notebook is a very different model from most
> IDEs.

I think for an out of the box working environment, I would include
both ipython and spyder.
One reason is that it requires packaging or instructions for their
dependencies, especially pyside/pyqt
( I have inconsistent versions in my Windows python versions but I'm
not interested enough to figure out how to get the qtconsole to work
after each update.)

ipython's popularity is unquestionable, in statsmodels we start to
include notebooks as part of the documentation
spyder gives a similar GUI as other packages that Windows user will be
familiar with (Matlab, Stata without the stats specific menus, ...)

my 2c

Josef

>
> What do other people think? If we did specify an interface, is there
> anything we could do to maintain interest in the alternatives?
>
> Best wishes,
> Thomas
> _______________________________________________
> SciPy-User mailing list
> SciPy-User@scipy.org
> http://mail.scipy.org/mailman/listinfo/scipy-user


More information about the SciPy-User mailing list