On 01/27/2015 03:11 PM, Carlos Córdoba wrote:
Hi Gonzalo,
My answers are below
El 27/01/15 a las 17:10, Gonzalo Peña-Castellanos escribió:
Hi again users and devs :)
Now looks is not everything and I wanted to also talk a bit a bit about
what defaults should we have on Spyder when starting fresh, some
widgets and also plugins
*The template*
The template is what every noob will see the first time they start
Spyder,
why not make the best we can to have the best but minimal template?
* Include a def main ():
* Include the boilerplate (if __name__ == "__main__": main())
* Include the basic scientific imports with their standard aliases
o (numpy as np, scipy as sp, matplotlib.pyplot as plt...
o shebang (# /usr/bin/env python)
I don't agree with most of these changes:
1. There is no need to define a main function to run a file, at least
not inside Spyder.
2. if __name__ == "__main__" is a Python idiom that would surely confuse
beginners. Besides, I've used it very few times in my years using Python :-)
Besides which if you have the above it will run whatever is in there and
not let you do the poor mans debugging of running each step you would
call in main(), one at a time. In those cases where I have main() I
comment them out when doing the editing/running cycle. I for one think
the template should be the absolute minimum. It is not in Spyders
mission to enforce coding style on its users.
3. We can't include scientific import's by default because Spyder is
used to do several other things. Besides, if you're developing you own
library or something like that, you wouldn't like all your new files to
be filled with a lot of unnecessary imports :-)
+100
I am a biologist by training, but I do not use Spyder for scientific
purposes and dumping a bunch of imports into my namespace would not be
appreciated.
4. We could add a shebang in Posix systems, I'm fine with that one :-)
*PEP8 *
I think we should enforce the use of pep8 right from the start. Some
people
first experience with Python is through Spyder, why not enforce pep8 right
from the beginning when people are more easily persuaded?
Pep8 reports a lot of "trivial" things (like spaces between +) that
(again) can confuse beginners. I mean, I taught a Python class using
Spyder a couple of years ago, and my students always noticed and tried
to fix *all* reported errors.
So being annoyed by missing spaces, number of spaces between functions
and classes, etc, etc, seems like too much for people that are just
starting with the language (and probably won't touch it again :-)
Agreed. Important to remember PEP8 is a suggestion not a requirement.
Personally I try to stay close to it, but reserve the right to ignore it
when needed. Again Spyder is an IDE not a nanny.
Also on this line, why not make 'remove trailing spaces' also a default
We could think about this one. But then we would need to improve how we
handle automatic indentation.
In particular this open issue:
https://code.google.com/p/spyderlib/issues/detail?id=1896&can=4&colspec=ID%20MS%20Stars%20Priority%20Modified%20Cat%20Type%20Status%20Owner%20Summary
In addition, this a way of getting yourself into trouble with other
developers when sharing code. Removing their trailing spaces and
returning the code back to them, will get you 'noticed'. Again this is a
developer choice, not something an IDE needs to editorialize on.
*Object inspector*
The automatic connections seem like a great idea why not make at least
the editor
a default?
It was the default before 2.3 but I decided to make it optional because
it's very annoying to constantly see "dancing things" next to the Editor
when you are focused trying to solve a problem.
Ideally, users don't want to see documentation for *all* objects they
are using, just for the ones they need to. That's why I think it's
better to just offer Ctrl+I, and the option to activate the automatic
connection if people want it.
Agreed. There are enough things moving around. When I need the Object
Inspector I turn it on, otherwise it stays hidden.
*
*
*Online Help*
I hate this plugin, it looks horrible, I would argue that it needs to
go to the trash!
Yes, I'll remove it for 2.4 :-)
*Plugins*
The idea of plugins needs to be tackled ASAP. Of course the backbone
for this is already there
but we need to give the next step.
* Autodiscovery of plugins
* Make developing plugins inside Spyder simple providing templates
in the file explorer
* Provide through projects something similar (create a new Project
would give the option to make a spyder plugin)
* I think in the view menu we need to have Panes (Standard in
Spyder), and Plugins (3rd party plugins)
* I think plugins should be *pip* installable or/and, *conda*
installable (with the conda plugin)
* Once plugins are installable, profiler, pylint and conda packages
should go to their own repos
I agree with all these changes. I'll work on most of them for 2.4.
*Anaconda*
This might be a touchy subject for some, but I will go ahead anyway.
Before conda and the anaconda distribution the chances of getting
people in my institute to switch
to a Python based stack were pretty low. After anaconda, that has
dramatically changed and I expect a full
conversion (from matlab and delphi... yuck!) by the end of 2015 :)
I know there is winpython and python xy, and etc etc, but perhaps we
should enforce the use of anaconda
with a bit more enthusiasm.
The advantages are clear to me:
* Stable installation cross platform
* The use of conda environments allows for a compact and stable use
and reuse (sharing) of science :)
* A broad array of ready to use scientific packages
* The ability to use the conda package manager plugin inside Spyder
to install ALL of Spyder plugins
* The ability to have dedicated Spyder and Binstar
(https://binstar.org/dashboard) channels
o Provide dedicated experiences for different disciplines
o Have a metapackage to install all the basic optional
dependencies on spyder on one click
o Have a metapackage to install all the basic optional plugins
on spyder on one click
What are your thoughts on these issues I raise?
It's true that Anaconda is the future for Scientific Python. I agree
with having a Binstar channel and to improve the Spyder/Anaconda
integration when Spyder is ran from Anaconda.
But my feeling is that we should remain vendor neutral as much as we
can. We must respect how people wants to install and use Spyder. There
are a lot of ways to do that and all of them are valid and possible.
Agreed. Anaconda is really only useful for the Windows platform and from
the posts that show up here, even there it has issues. For those of us
that believe pip + virtenv is the better option, a move to Anaconda
would be a step backwards.
Cheers,
Carlos
--
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.
