On 12/11/2014 06:22 AM, Todd Rme wrote:
On Wed, Dec 10, 2014 at 7:56 PM, Gonzalo A. PEÑA CASTELLANOS
<[email protected]> wrote:
Hi guys, I have been discussing with some lecturers in my institute on how
to go on moving more people over python and spyder to improve our students
workflows and I was wondering what steps we should be taking to further
boost the adoption of spyder.
After erasing my current config, after opening spyder for the first
time, I think some work could be done optimizing the initial
experience. This includes the initial selection of panels, the
initial layout of panels, and making sure the panels don't expose too
much or too little to users.
Aside from that, the big issue for me is how spyder handles
"projects". These all have to be in subdirectories of one central
directory, as near as I can tell.
You can create a workspace anywhere. Just go the folder icon at the top
of the project page and select a new directory. Projects are contained
within a workspace. You can have multiple workspaces.
I don't organize my work that way,
which means that spyder is a non-started as my primary IDE. I have to
use one that allows projects in arbitrary locations (kdevelop in my
case). It probably makes things easier for people starting out, but I
think limits it greatly as a serious IDE. I think spyder should
certainly have a default directory for saving files and new projects,
but this shouldn't be a special directory otherwise. Settings should
all be stored either in the spyder config directory or in the project
directories themselves, not in the default directory, and projects
should just be directories with some hidden spyder file or directory
in it (tracked somewhere in the spyder configuration directory). This
would also imply, of course, importing existing directories without
moving or copying them (just put the hidden spyder file in it and
remember it somewhere in the spyder config directory).
In a workspace you can import a directory as a project with out copying
or moving by right clicking in the project area and doing
Import-->Existing directory. This assumes it is a sub-directory of the
workspace.
The lack of VCS integration (particularly git and hg in terms of
python) also make spyder a non-started for a lot of python
development, and increasingly scientific development (our group
recently got its own git server).
If you right click a file/directory in the File or Project Explorer you
get the option to Commit or Browse the repository. In my case this
brings up Tortoise Hg.
On the other hand, things important to Python are much harder than
they really need to be to make spyder useful as a primary python
shell. The primary issue I have is configuring default imports.
There is no real way to configure the imports for the default console
other than manually editing a file, and even the ipython shell only
has support for "pylab" mode and manually entering the imports (and
"pylab" mode is an approach that is discouraged by pretty much
everyone everywhere). There isn't even an obvious way to select an
ipython session.
So in this regard, I have some suggestions:
1. Import the more standard python scientific packages by default (as
long as they are installed). At the very least this would include
numpy, scipy, matplotlib, and pandas, but could also include things
like sympy, scikit-learn, and/or statsmodels.
Do not agree. Less is more. The number of issues that land on this list
already, due to the existing imports argues against increasing that.
This is especially true for people that install Spyder via one of the
pre-packaged solutions i.e Anaconda.
2. Import them into their own namespaces using the format normally
found in documentation ("import numpy as np", "import scipy as sp",
"import matplotlib.pyplot as plt", "import pandas as pd", etc.). Only
import numpy's "r_" into the global namespace (so "from numpy import
r_").
3. Make it easy to change what is imported. At the very least, have
an "imports" interface where you can check or uncheck any of these.
Better yet, scan for installed packages and let users check or uncheck
any package (and perhaps even set an alias for them, although this
might be too complicated for such an interface).
Best solution for this is to point people at the startup file and let
them customize how they want. Then they know who is holding the footgun:)
4. Ideally, use ipython sessions for this behind the scenes, and let
users choose the session when opening a new ipython tab.
There was some talk on other threads on maybe making a proper website and
improving it, including social media (twitter), improve documentation and
tutorials (via youtube/ vimeo) etc...
In terms of the website, here is an example of one I thought was
attractive while still being useful:
http://www.expyriment.org/
I know a lot of us use spyder and will most likely keep using it on years to
come (hopefully :) ) but I cant help but notice that in all
pydata/**enter_name_of_python_ conferece_here** you see always ipython
notebooks as the main material/tool, and spyder seems to be forgotten along
the way. With the inclusion of ipython nb editor inside spyder this
situation could improve, but how could we tackle this issue?
Yes, IPython notebook is good for display and light coding, but for more
involved work it gets in the way. An IDE is still better for complex
projects.
Yes, it seems that the scientific python ecosystem is standarizing on
the ipython notebook. So being able to use the ipython notebook in
spyder (qtwebkit, maybe?) seems to be getting more and more important
for spyder's success. The ipython notebook has some limitations that
spyder could address (lack of a variable explorer, lack of any real
debuggin system, etc).
I bring webdev, because I am finding myself more and more often thinking and
trying to develop (not yet developing anything serious) web
services/backends (django...) for apps in plans, that are also part of data
science and my scientific workflow.
Using web-based interfaces seems to be becoming more popular in
science. Supporting this sort of workflow (perhaps by being able to
embed a QtWebkit interface?) would probably be worthwhile. However, a
lot of the web-based interfaces seems to support interaction through
the ipython notebook, so perhaps using the ipython notebook as a
console would be sufficient for these purposes.
--
Adrian Klaver
[email protected]
--
You received this message because you are subscribed to the Google Groups
"spyder" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
To post to this group, send email to [email protected].
Visit this group at http://groups.google.com/group/spyderlib.
For more options, visit https://groups.google.com/d/optout.
