Discussion:
[spyder] Spyder defaults, widgets, plugins and Anaconda
Gonzalo Peña-Castellanos
2015-01-27 22:10:41 UTC
Permalink
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
- (numpy as np, scipy as sp, matplotlib.pyplot as plt...
- shebang (# /usr/bin/env python)

*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?

Also on this line, why not make 'remove trailing spaces' also a default

*Object inspector*
The automatic connections seem like a great idea why not make at least the
editor
a default?

*Online Help*
I hate this plugin, it looks horrible, I would argue that it needs to go to
the trash!

*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

*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
- Provide dedicated experiences for different disciplines
- Have a metapackage to install all the basic optional dependencies
on spyder on one click
- Have a metapackage to install all the basic optional plugins on
spyder on one click

What are your thoughts on these issues I raise?

Please comment and remember to follow/subscribe/like/request membership to
the new
Spyder communication channels

*Be Social*

- Twitter <https://twitter.com/spyder_ide>, Facebook
<https://www.facebook.com/SpyderIDE>, Google+ Page
<https://plus.google.com/u/0/b/107193318474220481102/107193318474220481102>

- Google+ Community
<https://plus.google.com/u/0/b/107193318474220481102/communities/112932801653352854842>
- Youtube channel
<https://www.youtube.com/channel/UCK0uCG7DVzKUAhaw8veitkw>
--
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 spyderlib+***@googlegroups.com.
To post to this group, send email to ***@googlegroups.com.
Visit this group at http://groups.google.com/group/spyderlib.
For more options, visit https://groups.google.com/d/optout.
Carlos Córdoba
2015-01-27 23:11:50 UTC
Permalink
Hi Gonzalo,

My answers are below
Post by Gonzalo Peña-Castellanos
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 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 :-)

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 :-)

4. We could add a shebang in Posix systems, I'm fine with that one :-)
Post by Gonzalo Peña-Castellanos
*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 :-)
Post by Gonzalo Peña-Castellanos
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.
Post by Gonzalo Peña-Castellanos
*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.
Post by Gonzalo Peña-Castellanos
*
*
*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 :-)
Post by Gonzalo Peña-Castellanos
*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.
Post by Gonzalo Peña-Castellanos
*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.
* 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.


Cheers,
Carlos
Post by Gonzalo Peña-Castellanos
Please comment and remember to follow/subscribe/like/request
membership to the new
Spyder communication channels
*Be Social*
* Twitter <https://twitter.com/spyder_ide>, Facebook
<https://www.facebook.com/SpyderIDE>, Google+ Page
<https://plus.google.com/u/0/b/107193318474220481102/107193318474220481102>
* Google+ Community
<https://plus.google.com/u/0/b/107193318474220481102/communities/112932801653352854842>
* Youtube channel
<https://www.youtube.com/channel/UCK0uCG7DVzKUAhaw8veitkw>
--
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
Visit this group at http://groups.google.com/group/spyderlib.
For more options, visit https://groups.google.com/d/optout.
--
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 spyderlib+***@googlegroups.com.
To post to this group, send email to ***@googlegroups.com.
Visit this group at http://groups.google.com/group/spyderlib.
For more options, visit https://groups.google.com/d/optout.
Adrian Klaver
2015-01-27 23:40:39 UTC
Permalink
Post by Carlos Córdoba
Hi Gonzalo,
My answers are below
Post by Gonzalo Peña-Castellanos
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 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)
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.
Post by Carlos Córdoba
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.
Post by Carlos Córdoba
4. We could add a shebang in Posix systems, I'm fine with that one :-)
Post by Gonzalo Peña-Castellanos
*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.
Post by Carlos Córdoba
Post by Gonzalo Peña-Castellanos
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.
Post by Carlos Córdoba
Post by Gonzalo Peña-Castellanos
*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.
Post by Carlos Córdoba
Post by Gonzalo Peña-Castellanos
*
*
*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 :-)
Post by Gonzalo Peña-Castellanos
*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.
Post by Gonzalo Peña-Castellanos
*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.
* 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.
Post by Carlos Córdoba
Cheers,
Carlos
--
Adrian Klaver
***@aklaver.com
--
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 spyderlib+***@googlegroups.com.
To post to this group, send email to ***@googlegroups.com.
Visit this group at http://groups.google.com/group/spyderlib.
For more options, visit https://groups.google.com/d/optout.
Gonzalo Peña-Castellanos
2015-01-28 07:49:45 UTC
Permalink
First of all, thanks for sharing your views on the issues I raised,

I really appreciate all your comments and input and Spyder greatly
benefits from them.

*I know all this are personal opinions but I would like for you to always *
*look at Spyder through the eyes of a new user, not a developer,*
*not a hacker, not an old time user.*

Now on the issues raised

*Template*
Sorry I needed to elaborate more on this, that was the "old time user"
talking!

I really like the suggestion from André, we could have some "standard"
templates,
and we could even allow for easy creation of more templates.

This way you could tailor your default templates.

- Blank
- Scientific Stack template

I am aware of the weirdness of the boilerplate, I was unaware of it
for a long time, but when I started making my own modules it all
made sense. I also know it is hard to teach what it does and why
it look so weird BUT is something worth getting straight from the
beginning, no?

Dumping import in the namespace is relative... templates are meant for
the editor and erasing lines is easier than writing

*PEP*
I am well aware of the optional quality of PEP in the python world.
I was also unaware of PEP for a while and my scripts looked pretty
bad (hell maybe they still do!) but once I learned about my code
really looks clean to the point, that I type it like that and the
"annoyance"
is minimal. Would not this be something to foster in new generations?
If you "annoy" them at the beginning you might actually make clean
python programmers as a side effect, is that something bad to wish for ;) ?

As André, I also have a small background in teaching Python (with Spyder)
and this is something needed

The removing of trailing and empty lines is what gets triggered often in
PEP8,
mostly because autoindent should remove and empty space if you hit enter
twice, so that this indented empty lines would not get generated.

This really would benefit the new comers and people teaching them

*Online help*
André raises a good point, but it looks so ugly!!! any alternative to this?
maybe styling the output with a custom css to make it look consistent
and pretty with Spyder then??

*Object inspector*
Yes I see the point, I still miss it how it was before :(

*Language*
I agree with André, you should be able to ste the language to whatever
you want and not get any "unexpected" stuff by using LANG defaults.

*Anaconda*
I would argue anaconda is the present. The thing is that is Windows
for better or worse will still remain the OS of choice of institutions
worldwide and most new people will come from a windows background
so we should strive to make this the default.

For a linux user that only uses Linux, and learn linux 5 years ago,
fine, you know how to hack away in linux, and will use apt to do
everything

For the new and recent linux user (ubuntu, mint... etc..) with a pretty
interface and no command line needed (in general).. anaconda is also
great.

For the cross platform user, anaconda IS A MUST!

If people have not work on science with numpy scipy, mpi etc on windows
then the argument of "pip and virtual env is enough" will never be
backwards.
Pip is a great tool and still needed, virtual_env is pretty useless if you
go
outside of Python only libraries, I know is quick and easy.

Even on Linux and trying to share your work with only pip and virtual env
wont do. The new projects features could immensely benefit if we used conda
environments as a core of it.

Here is an idea. We also have Minconda
<http://conda.pydata.org/miniconda.html> available.

Should we create a custom installer with minconda + Spyder + numpy + scipy +
optional but very usefull dependencies on Spyder? We could even ask for the
help at conitnuum.

It would not be so heavy as anaconda and it could carry everything needed
and
it could already leverage conda for projects and the installation of
packages.

Whats more, conda allows for installing R packages now (in beta testing) so
we
could potentially add an R console to Spyder for people still needing
R!!!!!!!

Thanks for sharing, cheers
--
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 spyderlib+***@googlegroups.com.
To post to this group, send email to ***@googlegroups.com.
Visit this group at http://groups.google.com/group/spyderlib.
For more options, visit https://groups.google.com/d/optout.
j***@gmail.com
2015-01-28 16:31:39 UTC
Permalink
On Wed, Jan 28, 2015 at 2:49 AM, Gonzalo Peña-Castellanos <
Post by Gonzalo Peña-Castellanos
First of all, thanks for sharing your views on the issues I raised,
I really appreciate all your comments and input and Spyder greatly
benefits from them.
*I know all this are personal opinions but I would like for you to always *
*look at Spyder through the eyes of a new user, not a developer,*
*not a hacker, not an old time user.*
Why, I have been using spyder since it had a different name, and I don't
want it to become "newbie only".

Even new users turn into old users after a few months and want to GTD.

I don't disagree with improvements for new users, but most of the usage is
by old users.
("You learn it once and use it the rest of your life." )
Post by Gonzalo Peña-Castellanos
Now on the issues raised
*Template*
Sorry I needed to elaborate more on this, that was the "old time user"
talking!
I really like the suggestion from André, we could have some "standard"
templates,
and we could even allow for easy creation of more templates.
This way you could tailor your default templates.
- Blank
- Scientific Stack template
I am aware of the weirdness of the boilerplate, I was unaware of it
for a long time, but when I started making my own modules it all
made sense. I also know it is hard to teach what it does and why
it look so weird BUT is something worth getting straight from the
beginning, no?
Dumping import in the namespace is relative... templates are meant for
the editor and erasing lines is easier than writing
*PEP*
I am well aware of the optional quality of PEP in the python world.
I was also unaware of PEP for a while and my scripts looked pretty
bad (hell maybe they still do!) but once I learned about my code
really looks clean to the point, that I type it like that and the
"annoyance"
is minimal. Would not this be something to foster in new generations?
If you "annoy" them at the beginning you might actually make clean
python programmers as a side effect, is that something bad to wish for ;) ?
As André, I also have a small background in teaching Python (with Spyder)
and this is something needed
The removing of trailing and empty lines is what gets triggered often in
PEP8,
mostly because autoindent should remove and empty space if you hit enter
twice, so that this indented empty lines would not get generated.
This really would benefit the new comers and people teaching them
The automatic pep-8 tools are pretty bad, too much enforcement of
questionable rules.
scipy has an automatic check of PRs for pep-8 with lots of exceptions and
still there are weird things.
The main things I don't like are some of the whitespace and optional
indentation rules.

I'm using spyder mainly for initial development of new code and scripts and
the error markers are very useful. Having pep-8 automatically included
would be just a distraction.

I still run pep-8 checks from time to time ignoring all the false positive,
same with pylint.

http://bugs.python.org/issue18472?utm_source=buffer&utm_campaign=Buffer&utm_content=buffer43924&utm_medium=facebook#msg193909
Post by Gonzalo Peña-Castellanos
*Online help*
André raises a good point, but it looks so ugly!!! any alternative to this?
maybe styling the output with a custom css to make it look consistent
and pretty with Spyder then??
*Object inspector*
Yes I see the point, I still miss it how it was before :(
*Language*
I agree with André, you should be able to ste the language to whatever
you want and not get any "unexpected" stuff by using LANG defaults.
*Anaconda*
I would argue anaconda is the present. The thing is that is Windows
for better or worse will still remain the OS of choice of institutions
worldwide and most new people will come from a windows background
so we should strive to make this the default.
For a linux user that only uses Linux, and learn linux 5 years ago,
fine, you know how to hack away in linux, and will use apt to do
everything
For the new and recent linux user (ubuntu, mint... etc..) with a pretty
interface and no command line needed (in general).. anaconda is also
great.
For the cross platform user, anaconda IS A MUST!
If people have not work on science with numpy scipy, mpi etc on windows
then the argument of "pip and virtual env is enough" will never be
backwards.
Pip is a great tool and still needed, virtual_env is pretty useless if you
go
outside of Python only libraries, I know is quick and easy.
Even on Linux and trying to share your work with only pip and virtual env
wont do. The new projects features could immensely benefit if we used conda
environments as a core of it.
Here is an idea. We also have Minconda
<http://conda.pydata.org/miniconda.html> available.
Should we create a custom installer with minconda + Spyder + numpy + scipy +
optional but very usefull dependencies on Spyder? We could even ask for the
help at conitnuum.
It would not be so heavy as anaconda and it could carry everything needed
and
it could already leverage conda for projects and the installation of
packages.
Whats more, conda allows for installing R packages now (in beta testing)
so we
could potentially add an R console to Spyder for people still needing
R!!!!!!!
I think spyder should stay an IDE and stay out of the packaging business,
even if it provides optional support.

I'm on Windows I initially got python-xy for this notebook, I also have
anaconda and winpython, and another 3 pythons installed without
packaging/distribution.

Josef
Post by Gonzalo Peña-Castellanos
Thanks for sharing, cheers
--
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
Visit this group at http://groups.google.com/group/spyderlib.
For more options, visit https://groups.google.com/d/optout.
--
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 spyderlib+***@googlegroups.com.
To post to this group, send email to ***@googlegroups.com.
Visit this group at http://groups.google.com/group/spyderlib.
For more options, visit https://groups.google.com/d/optout.
Adrian Klaver
2015-01-28 19:55:56 UTC
Permalink
Post by Gonzalo Peña-Castellanos
First of all, thanks for sharing your views on the issues I raised,
I really appreciate all your comments and input and Spyder greatly
benefits from them.
*I know all this are personal opinions but I would like for you to always *
*look at Spyder through the eyes of a new user, not a developer,*
*not a hacker, not an old time user.*
Now on the issues raised
*Template*
Sorry I needed to elaborate more on this, that was the "old time user"
talking!
I really like the suggestion from André, we could have some "standard"
templates,
and we could even allow for easy creation of more templates.
This way you could tailor your default templates.
* Blank
* Scientific Stack template
I am aware of the weirdness of the boilerplate, I was unaware of it
for a long time, but when I started making my own modules it all
made sense. I also know it is hard to teach what it does and why
it look so weird BUT is something worth getting straight from the
beginning, no?
Dumping import in the namespace is relative... templates are meant for
the editor and erasing lines is easier than writing
*PEP*
I am well aware of the optional quality of PEP in the python world.
I was also unaware of PEP for a while and my scripts looked pretty
bad (hell maybe they still do!) but once I learned about my code
really looks clean to the point, that I type it like that and the
"annoyance"
is minimal. Would not this be something to foster in new generations?
If you "annoy" them at the beginning you might actually make clean
python programmers as a side effect, is that something bad to wish for ;) ?
As André, I also have a small background in teaching Python (with Spyder)
and this is something needed
The removing of trailing and empty lines is what gets triggered often in
PEP8,
mostly because autoindent should remove and empty space if you hit enter
twice, so that this indented empty lines would not get generated.
This really would benefit the new comers and people teaching them
*Online help*
André raises a good point, but it looks so ugly!!! any alternative to this?
maybe styling the output with a custom css to make it look consistent
and pretty with Spyder then??
*Object inspector*
Yes I see the point, I still miss it how it was before :(
*Language*
I agree with André, you should be able to ste the language to whatever
you want and not get any "unexpected" stuff by using LANG defaults.
*Anaconda*
I would argue anaconda is the present. The thing is that is Windows
for better or worse will still remain the OS of choice of institutions
worldwide and most new people will come from a windows background
so we should strive to make this the default.
For a linux user that only uses Linux, and learn linux 5 years ago,
fine, you know how to hack away in linux, and will use apt to do
everything
For the new and recent linux user (ubuntu, mint... etc..) with a pretty
interface and no command line needed (in general).. anaconda is also
great.
For the cross platform user, anaconda IS A MUST!
If people have not work on science with numpy scipy, mpi etc on windows
then the argument of "pip and virtual env is enough" will never be
backwards.
Pip is a great tool and still needed, virtual_env is pretty useless if
you go
outside of Python only libraries, I know is quick and easy.
Even on Linux and trying to share your work with only pip and virtual env
wont do. The new projects features could immensely benefit if we used conda
environments as a core of it.
Here is an idea. We also have Minconda
<http://conda.pydata.org/miniconda.html> available.
Should we create a custom installer with minconda + Spyder + numpy + scipy +
optional but very usefull dependencies on Spyder? We could even ask for the
help at conitnuum.
It would not be so heavy as anaconda and it could carry everything
needed and
it could already leverage conda for projects and the installation of
packages.
Whats more, conda allows for installing R packages now (in beta testing)
so we
could potentially add an R console to Spyder for people still needing
R!!!!!!!
Bottom line, you have an opinion of how and where you want to work on
Python. That is fine, but in the end it is your opinion, not necessarily
shared by others. Hard coding that into the design of Spyder is a no-go
from where I stand. The tools exist now for the end user to customize
the look, feel and operation of Spyder. These could be made easier and
more readily apparent and I think this is where work could be done. Also
at last look there were 487 open issues here:

https://code.google.com/p/spyderlib/issues/list

Seems to me that fixing these is bigger priority then starting on a
campaign that will only add to that list. If you want to help Spyder,
then I would suggest working on the Project manager. A fully functional
Project Manager would do more to 'sell' Spyder then anything else I can
think of.
Post by Gonzalo Peña-Castellanos
Thanks for sharing, cheers
--
Adrian Klaver
***@aklaver.com
--
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 spyderlib+***@googlegroups.com.
To post to this group, send email to ***@googlegroups.com.
Visit this group at http://groups.google.com/group/spyderlib.
For more options, visit https://groups.google.com/d/optout.
André Roberge
2015-01-28 20:06:37 UTC
Permalink
On Wednesday, 28 January 2015 03:49:45 UTC-4, Gonzalo Peña-Castellanos
Post by Gonzalo Peña-Castellanos
*Online help*
André raises a good point, but it looks so ugly!!! any alternative to this?
maybe styling the output with a custom css to make it look consistent
and pretty with Spyder then??
Hard-coded colors and style information are used in pydoc.py which serves
pages as HTML4 document.

I've removed all the hard-coded styling information and used html5 syntax
to create a modified version:

https://github.com/aroberge/mod_pydoc

This work was essentially inspired by this discussion. The new styling is
a quick-and-dirty job which
could definitely be improved upon.

Cheers,

André
--
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 spyderlib+***@googlegroups.com.
To post to this group, send email to ***@googlegroups.com.
Visit this group at http://groups.google.com/group/spyderlib.
For more options, visit https://groups.google.com/d/optout.
Gonzalo Peña-Castellanos
2015-01-28 20:13:20 UTC
Permalink
Hi André

Great job :), will definitely look into it as soon as I have time ;-)

Cheers
--
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 spyderlib+***@googlegroups.com.
To post to this group, send email to ***@googlegroups.com.
Visit this group at http://groups.google.com/group/spyderlib.
For more options, visit https://groups.google.com/d/optout.
Yuxiang Wang
2015-01-28 21:56:28 UTC
Permalink
One thought about the default setting:

Would you think for IPython QtConsole, the Automatic figure would be better
than the Inline? The reason for that is:

1) Matlab used a pop-out figure, which is what matplotlib originally set
out to mimic;
2) For a scientific use, the interactive plotting is very often used;
3) For a scientific publication, the ppi needs to be >= 300. And as a
consequence, inline figure with ppi >= 300 will be too large to fit in the
window.

Shawn


On Wednesday, January 28, 2015 at 3:13:20 PM UTC-5, Gonzalo
Post by Gonzalo Peña-Castellanos
Hi André
Great job :), will definitely look into it as soon as I have time ;-)
Cheers
--
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 spyderlib+***@googlegroups.com.
To post to this group, send email to ***@googlegroups.com.
Visit this group at http://groups.google.com/group/spyderlib.
For more options, visit https://groups.google.com/d/optout.
Yuxiang Wang
2015-01-28 22:16:07 UTC
Permalink
One more comment - should be using "Qt" rather than "Automatic".
"Automatic" does not work when I try to close a figure currently in Windows
for now (see
https://groups.google.com/forum/?fromgroups#!topic/spyderlib/UyWJe_cbxr8 ).

Shawn
Post by Yuxiang Wang
Would you think for IPython QtConsole, the Automatic figure would be
1) Matlab used a pop-out figure, which is what matplotlib originally set
out to mimic;
2) For a scientific use, the interactive plotting is very often used;
3) For a scientific publication, the ppi needs to be >= 300. And as a
consequence, inline figure with ppi >= 300 will be too large to fit in the
window.
Shawn
On Wednesday, January 28, 2015 at 3:13:20 PM UTC-5, Gonzalo
Post by Gonzalo Peña-Castellanos
Hi André
Great job :), will definitely look into it as soon as I have time ;-)
Cheers
--
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 spyderlib+***@googlegroups.com.
To post to this group, send email to ***@googlegroups.com.
Visit this group at http://groups.google.com/group/spyderlib.
For more options, visit https://groups.google.com/d/optout.
Julien Hillairet
2015-01-28 22:28:48 UTC
Permalink
Dear all,
Post by Yuxiang Wang
Would you think for IPython QtConsole, the Automatic figure would be
better than the Inline?
I totally agree. The first thing we do when we teach Python with Spyder is
to setup Spyder in order to disable the inline mode, which is confusing for
people coming from Matlab.

By the way, why to the new figures open behind Spyder (without focus) ?

julien
--
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 spyderlib+***@googlegroups.com.
To post to this group, send email to ***@googlegroups.com.
Visit this group at http://groups.google.com/group/spyderlib.
For more options, visit https://groups.google.com/d/optout.
Ronan Paixão
2015-01-30 01:10:24 UTC
Permalink
Post by Julien Hillairet
By the way, why to the new figures open behind Spyder (without focus) ?
I've also had problems with windows opening behind Spyder.
Not only figures, but other PyQt apps as well.

On the packaging thing, I have in other threads suggested a
package manager. I'd just like to remember that on the occasion
I did say that this should not be Spyder's trouble. Now, seeing
the conda package manager plugin, I have to say that it looks
pretty cool, even if out of place. But even though it benefits me
as I use Anaconda on Windows, I have to keep my point straight:
since it is already there, the plugin is nice, but should remain as
a plugin. The most important thing to keep in mind is that Spyder
was chosen by Python(x,y), WinPython and Anaconda (I think
in that order, in time of appearance). Well, no matter who came
first or who has more features, Spyder is in them all. If conda
becomes a dependency for Spyder, we alienate two of three
communities, and the two earlier ones, at worst. Remember
that people become attached to their Python distro, as much
as Linux distros.

So, depending on conda pretty much "locks out" a huge userbase.
And that is independent of the skill levels of the user. In fact,
I believe that to convert newbies, an IDE has to be useful and
powerful for pro users. Think of it: if we convert a teacher, we
pretty much have access to all of his class(es). And to convert a
teacher, I think we are on the right track. Be useful immediately
for writing simple scripts for teaching, as well as be an actually
useful IDE for interactive work. Spyder is pretty good by using
Matlab's (and other IDEs') cell run structure, and the line run (F9)
is pretty good to. So all we have to do that is NOT break it and
keep it simple. On the other hand, to actually *retain* the users,
Spyder must be powerful, so here comes other features like
debugging and projects. In short: we must be careful to make
really useful features, that won't bloat or slow down pro users.
Think of how SublimeText got its fame. I don't want to go to that
extreme, but we must be able to learn something from that.

To end, not wanting to start a flame war but just about to:
1) I think MKL doesn't come with Python(x,y) for some time now.
I think the only free-as-in-beer Python MKL out there is
Cristoph Gohlke's. But I may be wrong.

2) Even though a lot of Spyder's power users use Linux, and
power users are the ones who actually develop Spyder, we
simply cannot dismiss Windows with our prejudices. As much
as I'd like it to be true, Windows isn't going away anytime soon.
Anyone who works in any non-tech oriented (or tech-as-a-tool)
company has to deal with it. I myself "had" to go back to Windows
after 7 years of Linux as my desktop OS, because I simply
couldn't bother having to find two ways of doing everything
(one for home Linux and one for work Windows). Back from the
trolling, a lot of newbies come using OEM Windows machines
at home, and a lot of pros can use Spyder on Windows at work.
So, we must support it somehow.

3) There isn't a lot in the way of "system icons" on Windows.
A sign of this is cross-platform software that has a big Windows
userbase. Take browsers, for example. Most have it's own icons
and some have whole skin/theme-able interfaces. Even Windows
itself has many "skins": 95/98, XP, Vista, 7, 8 (Classic, Aero,
Metro styles). A whole mess really. The point is that Qt is fine
for using native style, but do we have to go all the way to the
icon theme? Just note that Qt doesn't come with "native icons"
for Windows, but if that is the problem, it may be possible to
use QIcon's theme methods. As such, it may be possible to
use system icons where available, but it is my opinion that
some icons won't be available on a lot of icon sets, which
will result in broken overall design. And no, it's most
probably not viable to maintain supplementary icons for each
icon set out there. Maybe for some major icon sets, but
who will do that? Volunteers?
--
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 spyderlib+***@googlegroups.com.
To post to this group, send email to ***@googlegroups.com.
Visit this group at http://groups.google.com/group/spyderlib.
For more options, visit https://groups.google.com/d/optout.
Todd
2015-01-30 16:30:15 UTC
Permalink
Post by Ronan Paixão
1) I think MKL doesn't come with Python(x,y) for some time now.
I think the only free-as-in-beer Python MKL out there is
Cristoph Gohlke's. But I may be wrong.
Python(x,y) had MKL at least as of February 2014. I haven't seen anything
to indicate this has changed, and at least some indications it still did as
of at least September 2014.
Post by Ronan Paixão
2) Even though a lot of Spyder's power users use Linux, and
power users are the ones who actually develop Spyder, we
simply cannot dismiss Windows with our prejudices. As much
as I'd like it to be true, Windows isn't going away anytime soon.
Anyone who works in any non-tech oriented (or tech-as-a-tool)
company has to deal with it. I myself "had" to go back to Windows
after 7 years of Linux as my desktop OS, because I simply
couldn't bother having to find two ways of doing everything
(one for home Linux and one for work Windows). Back from the
trolling, a lot of newbies come using OEM Windows machines
at home, and a lot of pros can use Spyder on Windows at work.
So, we must support it somehow.
I don't see anyone proposing that we dismiss Windows, only that we not
forget that there are a lot of non-windows users, so we shouldn't tie
ourselves too closely to windows or focus too exclusively on approaches or
ways of thinking that are specific to windows.

3) There isn't a lot in the way of "system icons" on Windows.
Post by Ronan Paixão
A sign of this is cross-platform software that has a big Windows
userbase. Take browsers, for example. Most have it's own icons
and some have whole skin/theme-able interfaces. Even Windows
itself has many "skins": 95/98, XP, Vista, 7, 8 (Classic, Aero,
Metro styles). A whole mess really. The point is that Qt is fine
for using native style, but do we have to go all the way to the
icon theme? Just note that Qt doesn't come with "native icons"
for Windows, but if that is the problem, it may be possible to
use QIcon's theme methods. As such, it may be possible to
use system icons where available, but it is my opinion that
some icons won't be available on a lot of icon sets, which
will result in broken overall design. And no, it's most
probably not viable to maintain supplementary icons for each
icon set out there. Maybe for some major icon sets, but
who will do that? Volunteers?
As I explained, from a usability standpoint, I think native icons are the
most important, since people get used to the metaphors used in the theme.
This isn't a big problem for a web browser, where the number if icons is
usually pretty limited (it seems like internet explorer, firefox, and
chrome only have a handful), and even in that case the icons in the
browsers are actually pretty similar (nearly identical in most cases). But
as the number of tasks you have to do grows, so does the importance of
using metaphors you are familiar with.

Unforunately, it seems for windows that using the native icon theme is not
possible due to license restrictions. I am not sure the situation under
OsX, but it is also not possible. Only X11 currently allows automatically
using a native icon theme. That being said, I think using the native icon
theme where it is possible would be a big benefit. On X11, icon theme
follow a specification that automatically handles fallback when the icon
theme doesn't provide a given icon from the spec, so spyder doesn't need to
worry about that. Of course, letting people choose another installed icon
theme would be a good idea. Spyder already lets you choose another widget
theme, and QIcon lets you change the icon theme at runtime, so that
shouldn't be any more difficult. Spyder could also bundle an icon theme,
or at least the parts of one it needs, and when the platform does not
provide a default icon theme (as would be the case on Windows and Os X), it
can fall back on its bundled theme. That would simplify icon management in
general, since spyder could simply get the icon by name, rather than by
path.
--
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 spyderlib+***@googlegroups.com.
To post to this group, send email to ***@googlegroups.com.
Visit this group at http://groups.google.com/group/spyderlib.
For more options, visit https://groups.google.com/d/optout.
André Roberge
2015-01-27 23:38:17 UTC
Permalink
Post by Gonzalo Peña-Castellanos
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
I'm going to comment not as a scientist using Spyder, but as someone who is
teaching beginners (and want to use Spyder as their learning environment)
and
who has answered questions on the LearnPython subreddit from grad students
who were just beginning to learn Python and were using Spyder (and clearly
were in need of guidance). For these users, Spyder, in its default
configuration,
is overwhelming.
Post by Gonzalo Peña-Castellanos
*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 the boilerplate (if __name__ == "__main__": main())
- Include the basic scientific imports with their standard aliases
- (numpy as np, scipy as sp, matplotlib.pyplot as plt...
- shebang (# /usr/bin/env python)
How about having an easy to find option where one can have either a blank
template, or the template that you describe? (I'd suggest perhaps adding
a third standard one for unittests, and give users the possibility to define
their own templates easily.)
Post by Gonzalo Peña-Castellanos
*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?
Also on this line, why not make 'remove trailing spaces' also a default
+1 on that one.
Post by Gonzalo Peña-Castellanos
*Object inspector*
The automatic connections seem like a great idea why not make at least the
editor
a default?
*Online Help*
I hate this plugin, it looks horrible, I would argue that it needs to go
to the trash!
It's the standard default pydoc look ... yes, it looks bad (and I thought
so when I first used it
10 years ago, and still do) but it is a fantastic resource. If it's
removed, I'll just have
my students do
python -m pydoc -b
in a terminal window.
Post by Gonzalo Peña-Castellanos
*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
*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.
- 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
- Provide dedicated experiences for different disciplines
- Have a metapackage to install all the basic optional dependencies
on spyder on one click
- Have a metapackage to install all the basic optional plugins on
spyder on one click
What are your thoughts on these issues I raise?
I found Spyder through the Anaconda distribution myself: it made installing
many packages easy and
provides an ideal teaching environment for me and my students as it removes
the pain
of installing various required third-party packages.
Post by Gonzalo Peña-Castellanos
Please comment and remember to follow/subscribe/like/request membership to
the new
Spyder communication channels
One big issue for me: having the possibility to change the default language
of the UI. Yes, I know, it picks
it from the LANG environment. But, I do not want to change it for all my
programs; and I would like to
switch it back and forth depending on whether or not I'm teaching people
who are comfortable using English.


Cheers,

André
Post by Gonzalo Peña-Castellanos
*Be Social*
- Twitter <https://twitter.com/spyder_ide>, Facebook
<https://www.facebook.com/SpyderIDE>, Google+ Page
<https://plus.google.com/u/0/b/107193318474220481102/107193318474220481102>
- Google+ Community
<https://plus.google.com/u/0/b/107193318474220481102/communities/112932801653352854842>
- Youtube channel
<https://www.youtube.com/channel/UCK0uCG7DVzKUAhaw8veitkw>
--
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 spyderlib+***@googlegroups.com.
To post to this group, send email to ***@googlegroups.com.
Visit this group at http://groups.google.com/group/spyderlib.
For more options, visit https://groups.google.com/d/optout.
André Roberge
2015-01-28 06:23:41 UTC
Permalink
Post by André Roberge
One big issue for me: having the possibility to change the default
language of the UI. Yes, I know, it picks
it from the LANG environment. But, I do not want to change it for all my
programs; and I would like to
switch it back and forth depending on whether or not I'm teaching people
who are comfortable using English.
Just replying to myself (to help people who wanted this):
this is easily done in a temporary way (at least on Windows).
In a terminal window (cmd shell), all is needed is:

set lang = en
spyder

and spyder will start with the English UI (as opposed to the French default
in my case).
I guess there is no need to have a special environment variable to make a
more permanent change.


André
Post by André Roberge
Cheers,
André
Post by Gonzalo Peña-Castellanos
*Be Social*
- Twitter <https://twitter.com/spyder_ide>, Facebook
<https://www.facebook.com/SpyderIDE>, Google+ Page
<https://plus.google.com/u/0/b/107193318474220481102/107193318474220481102>
- Google+ Community
<https://plus.google.com/u/0/b/107193318474220481102/communities/112932801653352854842>
- Youtube channel
<https://www.youtube.com/channel/UCK0uCG7DVzKUAhaw8veitkw>
--
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 spyderlib+***@googlegroups.com.
To post to this group, send email to ***@googlegroups.com.
Visit this group at http://groups.google.com/group/spyderlib.
For more options, visit https://groups.google.com/d/optout.
Todd
2015-01-28 17:49:41 UTC
Permalink
On Tue, Jan 27, 2015 at 11:10 PM, Gonzalo Peña-Castellanos <
Post by Gonzalo Peña-Castellanos
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 the boilerplate (if __name__ == "__main__": main())
- Include the basic scientific imports with their standard aliases
- (numpy as np, scipy as sp, matplotlib.pyplot as plt...
- shebang (# /usr/bin/env python)
I would have from "__future__ import divison" (and maybe
"print_statement"), a shebang (it helps on POSIX and doesn't hurt on
windows, so always having it is good), and an encoding line and that is it.
Post by Gonzalo Peña-Castellanos
*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?
Also on this line, why not make 'remove trailing spaces' also a default
I think "remove trailing spaces only on lines I have edited" would be a
better default, so as not to create problems with git, hg, and other vcs.
Post by Gonzalo Peña-Castellanos
*Object inspector*
The automatic connections seem like a great idea why not make at least the
editor
a default?
*Online Help*
I hate this plugin, it looks horrible, I would argue that it needs to go
to the trash!
I would say that these can be combined and simplified. First, get rid of
the "source". If the same name exists in the editor and console, show a
dropdown to let the user pick. If the item is not found, show button in
the "no results found" to search online. Also have a button to search
online in the toolbar. Get rid of the "home" button, and don't show the
"index of modules" thing at all. Have a "reload" button that changes to a
"stop" button when reloading (the object inspector should have this anyway
to refresh the documentation for the current item). Put the "lock" button
inside the text entry field.
Post by Gonzalo Peña-Castellanos
*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.
I completely disagree. First of all, I use Linux, not windows. Linux
handles python just fine without the need for a separate python runtime.
Further, all major Linux distros provide package managers out-of-the-box
that are far better than conda, and my distro (openSUSE) and many others
provide far more python packages than anaconda does. It seems most Linux
distros provide spyder out-of-the-box, tying it to conda would eliminate
that entirely, greatly increasing the barrier of entry to Linux users
(which is a large portion of the technical computing user-base).

Second, anaconda is far from perfect. For non-academic users it requires
them to pay for an MKL license, while it is free for python xy. Python xy
also provides far more packages out-of-the-box. Winpython makes it easier
to set up portable python distributions. Anaconda certainly has its
advantages, but it is not the perfect solution in all situations.

Third, most of the benefits you listed, although they are benefits,
wouldn't directly help spyder. The only benefit would be the package
manager, which seems like a small benefit to throw away all other users.

I personally use anaconda on windows and network computers where I can't
update system packages, but on my main computers it would only cause me
trouble. This means I cannot use any software with a hard dependency on
conda.
--
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 spyderlib+***@googlegroups.com.
To post to this group, send email to ***@googlegroups.com.
Visit this group at http://groups.google.com/group/spyderlib.
For more options, visit https://groups.google.com/d/optout.
Adrian Klaver
2015-01-28 19:44:04 UTC
Permalink
On Tue, Jan 27, 2015 at 11:10 PM, Gonzalo Peña-Castellanos
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 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 would have from "__future__ import divison" (and maybe
"print_statement"), a shebang (it helps on POSIX and doesn't hurt on
windows, so always having it is good), and an encoding line and that is it.
No imports. You cut and paste from some other 2.X code into a new file
and now you are fighting the print, print() clean up and wondering why
division changed. If that is what you want, modify the template on your
machine.
*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?
Also on this line, why not make 'remove trailing spaces' also a default
I think "remove trailing spaces only on lines I have edited" would be a
better default, so as not to create problems with git, hg, and other vcs.
*Object inspector*
The automatic connections seem like a great idea why not make at
least the editor
a default?
*
*
*Online Help*
I hate this plugin, it looks horrible, I would argue that it needs
to go to the trash!
I would say that these can be combined and simplified. First, get rid
of the "source". If the same name exists in the editor and console,
show a dropdown to let the user pick. If the item is not found, show
button in the "no results found" to search online. Also have a button
to search online in the toolbar. Get rid of the "home" button, and
don't show the "index of modules" thing at all. Have a "reload" button
that changes to a "stop" button when reloading (the object inspector
should have this anyway to refresh the documentation for the current
item). Put the "lock" button inside the text entry field.
*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.
I completely disagree. First of all, I use Linux, not windows. Linux
handles python just fine without the need for a separate python
runtime. Further, all major Linux distros provide package managers
out-of-the-box that are far better than conda, and my distro (openSUSE)
and many others provide far more python packages than anaconda does. It
seems most Linux distros provide spyder out-of-the-box, tying it to
conda would eliminate that entirely, greatly increasing the barrier of
entry to Linux users (which is a large portion of the technical
computing user-base).
Second, anaconda is far from perfect. For non-academic users it
requires them to pay for an MKL license, while it is free for python
xy. Python xy also provides far more packages out-of-the-box.
Winpython makes it easier to set up portable python distributions.
Anaconda certainly has its advantages, but it is not the perfect
solution in all situations.
Third, most of the benefits you listed, although they are benefits,
wouldn't directly help spyder. The only benefit would be the package
manager, which seems like a small benefit to throw away all other users.
I personally use anaconda on windows and network computers where I can't
update system packages, but on my main computers it would only cause me
trouble. This means I cannot use any software with a hard dependency on
conda.
+1. Per another post, Spyder should not be a package manager, there are
enough of those already.
--
Adrian Klaver
***@aklaver.com
--
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 spyderlib+***@googlegroups.com.
To post to this group, send email to ***@googlegroups.com.
Visit this group at http://groups.google.com/group/spyderlib.
For more options, visit https://groups.google.com/d/optout.
Todd
2015-01-28 19:00:42 UTC
Permalink
On Tue, Jan 27, 2015 at 11:10 PM, Gonzalo Peña-Castellanos <
<snip>
I have some suggestions that I think would improve and simply the general
spyder UI. I already explained one, combining the object inspector and
online help. The others are below. Note that these are all suggestions.
when I say "should be", I am giving my personal preference (it would just
be too verbose to say "I think it should be that" every line). Feel free
to take or leave any of these as you see fit.

*Toolbars and Menus*


*File*

- Add a "Close other" action.
- "Load session" should open up a list of recent sessions, with an
option at the end to open a session from a file.
- There should be an option to rename the session
- Change "Revert" to "Reload file".

*Edit*

- Remove the "Delete" item from. There is a "Delete" key on the
keyboard.
- Keep a list of recent items from the clipboard below "copy", "cut",
and "paste".
- Have an "Overwrite mode" item. This should also be shown in the
status bar

*Search*

- Get rid of "Find next" and "Find previous". These are already in the
search bar.
- Move everything else to "Edit"
- Open "Go to line..." in a panel at the bottom of the editor like the
Find and Find/Replace panels.

*Source*

- "Convert end of line characters" should be moved into the statusbar,
with "End of line" being changed into a QtToolButton that show a menu when
pressed.
- "Fix indentation" should go in the *Edit* menu below the other
indentation actions.
- "Run static code analysis" should go in the *Run* menu below the
"Profile" action.
- "Remove trailing spaces" should be moved to *Edit*

*Run*

- The first two categories should be combined*. *They aren't really
logically separate.

*Debug*

- Flatten the menu. Move all the submenus to categories in the
top-level menu.

*Consoles*

- Move this to the "Consoles" panel. Add a "New tab" button in the
"Consoles" panel (more on this later) that is QtToolButton. When it is
pressed, it opens a console of the current type. If long-pressed, it opens
a menu whose contents are the same as the current *Consoles* menu.

*Tools*

- Add split view controls here.
- Add an option to lock the panels here.
- Add an option to show or hide pep8 issues in the editor.


*Panels*

*Object inspector / Online Help*

- Combine these into one panel (Just called "Object Inspector").
Normally, if you enter an object name it will do the same thing as "Object
inspect" currently. However, there will be a button to search online, or a
link at the top of the object information page. Further, if no results are
found locally, it will always show a button to search for help online.
- Get rid of the "Source" dropdown. If the object is present in the
console and the editor, show a dropdown in the text entry field that lets
the user pick one. (For example "Spam (Editor)" and "Spam (Console IPython
3258/A)", "Spam (Console Python 1)").
- Move the "lock" button into the text entry field".
- Add a "Reload" button that changes to a "Stop" button when loading.
This would refresh the page on online mode and re-read the object in local
mode.
- Get rid of the Online Help "Home" page entirely.
- Allow the user to open a "find" bar at the bottom in either mode,
opened from the "Edit" menu or whatever keyboard combination opens "find".

*Variable Explorer*

- For consistency, move the toolbar to the top.
- Users should be able to jump to the object inspector from the
right-click menu.
- "Refresh periodically" should be in the menu button.
- Most of the setting should be moved to the preferences.
- "Import" should be "Open".

*Project Explorer / Outline*

- These should be combined.
- Files from open projects should be listed, but so should open files
not in any project.
- It should be be a tree, with project names at the top (with a folder
icon), then files inside the project, then files not in any project listed
at the end.
- Open files should be highlighted, and projects should be expanded
automatically when a file in it is open.
- Files should be expandable with the outline inside.
- The outline toolbar should be eliminated, the expand/contract controls
should be in the right-click menu only.
- The "Open" interface for the project should be able to open projects
or files.

*Console* / *IPython Console* */ Internal Console*

- These should be combined.
- As mentioned previously, there should be a "New Tab" QtToolButton.
Pressing it once opens a new console that is the same as the current type,
or the same as the default type specified in the preferences (the default
option in preferences would be "same as current type"). Pressing and
holding brings up a menu to open a different type.
- The menu item to open the internal console should be hidden by
default. It must be enabled as an option in the preferences. It is greyed
out if it is already open.
- "Kill" and "Stop" buttons should be combined into just "Stop".
- The menu should be made as consistent as possible between the two.
Items not available in one type should be greyed out.

*History*

- Instead of a text field, this should be a tree view, organized by
session, with the current session expanded.
- There should be a button and a right-click menu to execute the
highlighted command (or multiple commands if more than one are
highlighted). Ideally each item would have a "Run" button next to it.
- Items should have small, italicized, desaturated text next to them
indicating which tab they came from.
- This should not be a tab view.
- Font should be system font.
- There should be an option to save selected history items, or all
history, to a file.

*Find in Files*

- This is extremely complicated.
- "Search" should change to "Stop" when running, they don't need
separate buttons.
- KDE's kate has a good way of handling this: there is a button to
expand additional options, which replaces the results list. When you do
the search, it disappears and the results list re-appears. This allows for
things to not be so cramped.
- You have "Regular expression" search in three places, with no clear
connection to what each should apply to, and using an icon I would never
guess is for "Regular expression". I would just use text instead of an
icon.
- There should be an "Open" button next to the folder item.
- The expand/contract buttons should be in the right-click menu only.
- All other toolbar items should be removed.

*Profiler*

- The Expand/Contract buttons should be in the right-click menu only.
- The "Profile" buttons should change to "Stop" when it is running.
- The file name and time should be in the title (like the file name is
in the Editor panel).
- There should be a QtToolButton with a list of files in open projects.
At the end should be an option to open an arbitrary file. The existing
text entry field and open file button should be removed.
- The "Output" button should be on the same line as the other buttons.

*Static code analysis*

- Probably just change the name to "Problems" (this is what kdevelop
calls it, I think it is much more obvious).
- The file name and time should be in the title (like the file name is
in the Editor panel).
- Again, "Analyze" should change to "Stop" when running.
- Again, "Output" should be on the same line.
- You shouldn't be able to open a file in the interface. It should use
the current file in the editor, or optionally all files in the current
project or all open files.
- There should be a button to open a config menu to change the analys
- Quality should be in the results panel, at the very end or very top.

*Find Bar*

- You should use up/down arrows not left-right arrows. First, you
aren't searching left and right in most cases, you are searching up and
down. Second, this could have locale-specific issues (going left goes down
in some languages).
- As I said, I don't think the icons are obvious. They should all be
text.
- The whole word/regex thing should probably be a dropdown menu ("Plain
text", "Whole word", "Regular Expression", KDE text editors also have
"Escape sequence").
- For simplicity, the KDE text editors only show the extra options like
regex and case when doing find/replace. They show it on the second line,
the same line as "Replace", which saves a lot of room and keeps the "Find"
interface very simple.
- "Replace all" should be a button, not a check box.
- "Replace/find" should just be "Replace", since it automatically starts
searching as soon as you type.
- There should be a check box to limit replacing only to the current
selection. It should be checked by default when more than one line is
selected.


*General*

I think that it would be good by default to use vertical tabs for the
panels, and let users hide all panels in a given toolbar. That way,
powerful tools can be available at a click without cluttering the interface
too much.
--
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 spyderlib+***@googlegroups.com.
To post to this group, send email to ***@googlegroups.com.
Visit this group at http://groups.google.com/group/spyderlib.
For more options, visit https://groups.google.com/d/optout.
Gonzalo Peña-Castellanos
2015-01-28 20:06:26 UTC
Permalink
Hi Adrian

Thanks for the answers, sincerely the idea of these posts is to explore
opinions, because that is at the end all we have, from these opinions
interesting ideas come up, even if you (or others) disagree with my
opinions.


*"Seems to me that fixing these is bigger priority then starting on
a campaign that will only add to that list."*

I am not starting any campaign, I am giving an opinion and asking for
more.

I am well aware of the number of issues and I am taking the lead in solving
some of them.

*"If you want to help Spyder, then I would suggest working on the Project*
*manager."*

This is what I have been working on since the past months (besides the
other minor PRs I helped with). A project manager would work best
if you could handle different python versions and different package
versions
as needed. virtual env and pip could do for python only packages, and I
have some work in this direction. For nonpython things, well conda+pip
work pretty well and I also have work in this direction.

Thanks again :)
--
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 spyderlib+***@googlegroups.com.
To post to this group, send email to ***@googlegroups.com.
Visit this group at http://groups.google.com/group/spyderlib.
For more options, visit https://groups.google.com/d/optout.
Adrian Klaver
2015-02-02 15:27:16 UTC
Permalink
Post by Gonzalo Peña-Castellanos
Hi Adrian
Thanks for the answers, sincerely the idea of these posts is to explore
opinions, because that is at the end all we have, from these opinions
interesting ideas come up, even if you (or others) disagree with my
opinions.
/"Seems to me that fixing these is bigger priority then starting on a
campaign that will only add to that list."/
I am not starting any campaign, I am giving an opinion and asking for
more.
I do not see the difference. The initial post had specific solutions
outlined, with a question tagged on the end. If this was really about
opinions the post would have only asked, what do you the end user want
from Spyder?. Instead a series of things where presented on which work
had already started and for which forgiveness was being asked. This does
not represent community to me.
Post by Gonzalo Peña-Castellanos
/
/
I am well aware of the number of issues and I am taking the lead in solving
some of them.
And it is appreciated, but lets stick to that before creating a new set
of issues, for instance

https://groups.google.com/forum/#!topic/spyderlib/4m2XJNVLYWQ
Post by Gonzalo Peña-Castellanos
/
/
/"If you want to help Spyder, then I would suggest working on the Project/
/manager."/
This is what I have been working on since the past months (besides the
other minor PRs I helped with). A project manager would work best
if you could handle different python versions and different package
versions
as needed. virtual env and pip could do for python only packages, and I
have some work in this direction. For nonpython things, well conda+pip
work pretty well and I also have work in this direction.
As long as these are kept as strictly optional plugins. I do not relish
the thought of an IDE I am using in Linux, carrying Windows baggage to
enable it to work in that developer unfriendly environment.
Post by Gonzalo Peña-Castellanos
Thanks again :)
--
Adrian Klaver
***@aklaver.com
--
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 spyderlib+***@googlegroups.com.
To post to this group, send email to ***@googlegroups.com.
Visit this group at http://groups.google.com/group/spyderlib.
For more options, visit https://groups.google.com/d/optout.
Carlos Córdoba
2015-02-08 01:04:28 UTC
Permalink
Hi all,

Please try to be respectful with each other. I think perhaps Gonzalo
tried to be a bit pushy about his opinions, which didn't provoke the
best reaction among the others.

My opinions and decisions about this thread are the following:

1. Anaconda

Perhaps this was the most controversial of all of Gonzalo's proposals.
My decision (as the current maintainer) is to remain vendor neutral, and
not to support any scientific distribution above the others. This is my
rationale:

* We don't have any hope to push something like this on Linux
distributions. If we'd try to, Linux packagers would simply patch Spyder
and remove the code related to Anaconda.

* I think this would be true too for source-based Mac distributions like
MacPorts and Fink.

* There is still a lot of effort and work going on on Windows
distributions like WinPython and PythonXY. I've heard they are used on
several workplaces, and not just by individual programmers. So, we don't
have any right to hinder them by trying to impose what we think is the
"best solution". At the end they would probably patch Spyder too to
remove the "problematic" code.

However, I want to state the following:

* I'm not opposed to improve Spyder integration with Anaconda, when
Spyder is running *inside* Anaconda. That's why I accepted the conda
package manager plugin, that some of you have seen already. But let me
assure you that this plugin will only be shown when we are 100% sure
Spyder version is an Anaconda one, and not in any other circumstance. We
won't promote it in the "Optional dependencies" dialog now anywhere else.

* To be consistent, I'll add more references to Anaconda in our "About
Spyder" dialog and Help menu. At the same time, I'll remove the actions
to use the WinPython package manager inside Spyder, and (I think) others
related to PythonXY. I had left them until now out of respect for
Pierre, but now that Spyder has grown beyond these distributions, I
think it's ok to remove those references.


2. Templates

I agree with adding more code templates (e.g. in the Source menu). We
could have scientific, data science and other kind of templates, which
would be really cool!

But as Adrian and I explained clearly, we can't impose any of those
templates by default. That would give the false impression that what's
in the template is *necessary* to program in Spyder (and we know that's
not true).

I don't have time to work on this, but as always, pull requests are
welcome :-)


3. PEP8

I'm really opposed to enable it by default. Look for example at this code:

1: # -*- coding: utf-8 -*-
2: """
3: Created on Sat Feb 7 19:35:42 2015
4:
5: @author: carlos
6: """
7:
8: def foo():
9: print("Hello, world!!")
10:

On line 8, PEP8 reports this incomprehensible error: "E382 expected two
blank lines, found 1". And if you forget line 10, then you'll see
another error. It's easy to understand what those errors mean when you
know what PEP8 is, but at first sight they seem like syntactical errors,
when they're really not! :-) That's why I mentioned this would confuse
beginners a lot.

However, I'm not opposed to nudge people in the PEP8 direction by
promoting it more. We already mention it in our tutorial, and we could
also mention it in one of our (soon to come) interactive tutorials.
There we could explain people what PEP8 is and why it's really useful.

We can also make the option more accessible, by putting it in the Source
menu, and in a more visible place in the Editor Preferences page.


4. Object Inspector

I already explained my rationale about not to automatically connect any
plugin to it by default. So far, I haven't seen complaints about it
(well, some users say automatic connections are not working correctly,
but I don't know why :-). So I'll take that as a sign that I didn't go
wrong with my decision.

About its speed: I made some tests and found that the first rendering
(of any page) can be quite slow, but after that the Object Inspector is
as fast as it always has been. If you are seeing a different behavior,
please use "hg bisect" to tell me when and where a speed regression was
introduced.


Well, I think that's all :-)

Cheers,
Carlos
Post by Adrian Klaver
Post by Gonzalo Peña-Castellanos
Hi Adrian
Thanks for the answers, sincerely the idea of these posts is to explore
opinions, because that is at the end all we have, from these opinions
interesting ideas come up, even if you (or others) disagree with my
opinions.
/"Seems to me that fixing these is bigger priority then starting on a
campaign that will only add to that list."/
I am not starting any campaign, I am giving an opinion and asking for
more.
I do not see the difference. The initial post had specific solutions
outlined, with a question tagged on the end. If this was really about
opinions the post would have only asked, what do you the end user want
from Spyder?. Instead a series of things where presented on which work
had already started and for which forgiveness was being asked. This
does not represent community to me.
Post by Gonzalo Peña-Castellanos
/
/
I am well aware of the number of issues and I am taking the lead in solving
some of them.
And it is appreciated, but lets stick to that before creating a new
set of issues, for instance
https://groups.google.com/forum/#!topic/spyderlib/4m2XJNVLYWQ
Post by Gonzalo Peña-Castellanos
/
/
/"If you want to help Spyder, then I would suggest working on the Project/
/manager."/
This is what I have been working on since the past months (besides the
other minor PRs I helped with). A project manager would work best
if you could handle different python versions and different package
versions
as needed. virtual env and pip could do for python only packages, and I
have some work in this direction. For nonpython things, well conda+pip
work pretty well and I also have work in this direction.
As long as these are kept as strictly optional plugins. I do not
relish the thought of an IDE I am using in Linux, carrying Windows
baggage to enable it to work in that developer unfriendly environment.
Post by Gonzalo Peña-Castellanos
Thanks again :)
--
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 spyderlib+***@googlegroups.com.
To post to this group, send email to ***@googlegroups.com.
Visit this group at http://groups.google.com/group/spyderlib.
For more options, visit https://groups.google.com/d/optout.
Big Stone
2015-02-01 14:08:07 UTC
Permalink
Hi,

Showing too much enthousiasm only for "Anaconda" may tie Spyder good
fortune even more to Continuum IO than it is today.


On Tuesday, January 27, 2015 at 11:10:41 PM UTC+1, Gonzalo Peña-Castellanos
Post by Gonzalo Peña-Castellanos
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 the boilerplate (if __name__ == "__main__": main())
- Include the basic scientific imports with their standard aliases
- (numpy as np, scipy as sp, matplotlib.pyplot as plt...
- shebang (# /usr/bin/env python)
*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?
Also on this line, why not make 'remove trailing spaces' also a default
*Object inspector*
The automatic connections seem like a great idea why not make at least the
editor
a default?
*Online Help*
I hate this plugin, it looks horrible, I would argue that it needs to go
to the trash!
*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
*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.
- 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
- Provide dedicated experiences for different disciplines
- Have a metapackage to install all the basic optional dependencies
on spyder on one click
- Have a metapackage to install all the basic optional plugins on
spyder on one click
What are your thoughts on these issues I raise?
Please comment and remember to follow/subscribe/like/request membership to
the new
Spyder communication channels
*Be Social*
- Twitter <https://twitter.com/spyder_ide>, Facebook
<https://www.facebook.com/SpyderIDE>, Google+ Page
<https://plus.google.com/u/0/b/107193318474220481102/107193318474220481102>
- Google+ Community
<https://plus.google.com/u/0/b/107193318474220481102/communities/112932801653352854842>
- Youtube channel
<https://www.youtube.com/channel/UCK0uCG7DVzKUAhaw8veitkw>
--
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 spyderlib+***@googlegroups.com.
To post to this group, send email to ***@googlegroups.com.
Visit this group at http://groups.google.com/group/spyderlib.
For more options, visit https://groups.google.com/d/optout.
Loading...