Spyder defaults, widgets, plugins and Anaconda

[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 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, Facebook, Google+ Page 
  
• Google+ Community
• Youtube channel

 

[Carlos Córdoba]

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
• (numpy as np, scipy as sp, matplotlib.pyplot as plt...
• 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 :-)

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

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.

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.

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

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

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

Spyder communication channels

Be Social

• Twitter, Facebook, Google+ Page 
  
• Google+ Community
• Youtube channel

 

--
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 spyd...@googlegroups.com.
Visit this group at http://groups.google.com/group/spyderlib.
For more options, visit https://groups.google.com/d/optout.

[André Roberge]

On Tuesday, 27 January 2015 18:10:41 UTC-4, Gonzalo Peña-Castellanos wrote:

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.

 

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)

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

 

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. 

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.

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.

 

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é

[Adrian Klaver]

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
adrian...@aklaver.com

[André Roberge]

On Tuesday, 27 January 2015 19:38:17 UTC-4, André Roberge wrote:

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é

[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 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

[josef...@gmail.com]

On Wed, Jan 28, 2015 at 2:49 AM, Gonzalo Peña-Castellanos <goan...@gmail.com> wrote:

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." )

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

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

 

Thanks for sharing, cheers

[Todd]

On Tue, Jan 27, 2015 at 11:10 PM, Gonzalo Peña-Castellanos <goan...@gmail.com> wrote:

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)

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.

 

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.

[Todd]

On Tue, Jan 27, 2015 at 11:10 PM, Gonzalo Peña-Castellanos <goan...@gmail.com> wrote:

<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.

[Adrian Klaver]

On 01/28/2015 09:49 AM, Todd wrote:
> On Tue, Jan 27, 2015 at 11:10 PM, Gonzalo Peña-Castellanos
> <goan...@gmail.com <mailto:goan...@gmail.com>> wrote:
>
> 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 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*

+1. Per another post, Spyder should not be a package manager, there are
enough of those already.




--
Adrian Klaver
adrian...@aklaver.com

[Adrian Klaver]

On 01/27/2015 11:49 PM, Gonzalo Peña-Castellanos wrote:
> 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.

>
> Thanks for sharing, cheers
>


--

Adrian Klaver
adrian...@aklaver.com

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

[André Roberge]

On Wednesday, 28 January 2015 03:49:45 UTC-4, Gonzalo Peña-Castellanos wrote:

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é

 

[Gonzalo Peña-Castellanos]

Hi André

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

Cheers

[Yuxiang Wang]

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

[Yuxiang Wang]

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

[Julien Hillairet]

Dear all,

2015-01-28 22:56 GMT+01:00 Yuxiang Wang <wangyux...@gmail.com>:

One thought about the default setting:

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

[Ronan Paixão]

2015-01-28 20:28 GMT-02:00 Julien Hillairet <julien.h...@gmail.com>:

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?

[Todd]

On Fri, Jan 30, 2015 at 2:10 AM, Ronan Paixão <ronan...@gmail.com> wrote:

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.

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.

 

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.

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.

[Big Stone]

Hi,

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

[Adrian Klaver]

On 01/28/2015 12:06 PM, Gonzalo Peña-Castellanos wrote:
> 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.

> /
> /

> 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

> /
> /
> /"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.


>
> Thanks again :)
>


--
Adrian Klaver
adrian...@aklaver.com

[Carlos Córdoba]

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

El 02/02/15 a las 10:27, Adrian Klaver escribió: