[SciPy-User] Pylab - standard packages

josef.pktd@gmai... josef.pktd@gmai...
Fri Sep 21 09:39:30 CDT 2012


On Fri, Sep 21, 2012 at 9:59 AM, Thomas Kluyver <takowl@gmail.com> wrote:
> On 21 September 2012 12:40, Almar Klein <a.klein@science-applied.nl> wrote:
>> My main objection it that any chosen interface should not be implied as
>> *the* interface. For instance, Python(x,y) should still be pylab compliant
>> even though it uses Spyder as an interface. I suppose it's not hard for
>> Python(x,y) to include the IPython executable in the distribution. (As
>> opposed to integrating an IPython kernel with Spyder, which is obviosuly
>> much harder.)
>
> Of course, distributions would still be able to ship more than one
> interface, and write their own documentation pointing people towards
> Spyder, for example. But a Pylab tutorial might say e.g. "go to a
> terminal and start 'ipython notebook'", and we'd want that to work for
> anyone who had installed a pylab distribution.
>
>> Further, you made a point about being able to share richer code documents
>> specific to the chosen interface. I strongly think that we should make
>> sharing code independent of the interface. Of course, withing a specific
>> user group, users are free to use specific formats, my point is that it
>> should not be encouraged from pylab.
>
> There is a desire to store data besides raw code, and the community is
> already starting to pick up ipynb files for that. I'm not sure about
> encouraging it, but I think the standard should enable people to
> exchange those files, at least.
>
> Nathaniel:
>> - A "pylab shell"
>
> I'd rather not say 'it has to work x much like IPython, but it needn't
> be IPython'. If we do that, most distributions will ship IPython, and
> users of the odd one that doesn't will be stuck unable to use features
> everyone else has, and documentation might assume they have.
>
> Another argument for specifying IPython is that all the distributions
> we've discussed so far already ship it. Only Python(x,y) has an old
> version, but we're working on that. EPD (inc EPD Free), Anaconda,
> Sage, QSnake and WinPython all seem to have a more recent version. It
> is a de facto standard for scientific Python distributions. I see this
> as a push to formalise the de facto standards, the packages that we
> all know about, so newcomers don't need to hunt these out themselves.
>
> Again, I'll draw a parallel with R. R ships with a lightweight IDE,
> and tutorials can assume you have that, but it hasn't stopped
> alternatives like RStudio and Tinn-R gaining popularity. Once
> programmers are comfortable with the language, they go looking for the
> tools that suit them best. But I think we would be doing users a
> disservice if introductory documentation couldn't assume any
> particular interface.

R is awful, and it's starting to clean up the IDE situation recently
(I haven't tried R Studio yet).
The included interface is much worse than IDLE. The last full GUI with
statistics menu crashed R after a few hours of work. The
recommendations for GUIs, IDEs are all over the place.

Stata and matlab have a much nicer interaction of shell and editor,
and data viewer, and ...
and they work after clicking a few install buttons (and paying first of course).

Obviously I'm in a minority, I like Windows (TM), GUIs, spyder, git
gui and use ipython only in emergencies.

Josef

>
> Best wishes,
> Thomas
>
> P.S. Nathaniel: you describe trying to set conventions for how to test
> packages or find documentation, not to mention installing packages. I
> agree with all of that, but I'd like to put it under 'battles to fight
> another day'. If we're going to do anything, we can't try to do
> everything.
> _______________________________________________
> SciPy-User mailing list
> SciPy-User@scipy.org
> http://mail.scipy.org/mailman/listinfo/scipy-user


More information about the SciPy-User mailing list