Hi all,
I am pleased to announced that Spyder v2.0.8 has just been released. As this is mostly a maintenance release, a lot of bugs were fixed (see below) and some minor features were added. Integration Spyder's GUI-based Python shell in your application: Note that this version includes an example of application using the Spyder's internal shell as a debugging console which also demonstrates the py2exe deployment procedure. Spyder (previously known as Pydee) is a free open-source Python development environment providing MATLAB-like features in a simple and light-weighted software, available for Windows XP/Vista/7, GNU/Linux and MacOS X: http://spyderlib.googlecode.com/ Spyder is part of spyderlib, a Python module based on PyQt4, pyflakes and rope (QScintilla's dependency has been removed in version 2.0 and rope features have been integrated since this version as well). Some of Spyder basic features: * Python, C/C++, Fortran source editor with class/function browser, code completion and calltips * consoles: o open as many Python interpreters, IPython consoles or command windows as you need o code completion and calltips o variable explorer with GUI-based editors for a lot of data types (numbers, strings, lists, arrays, dictionaries, ...) * object inspector: provide documentation or source code on any Python object (class, function, module, ...) * online documentation: automatically generated html documentation on installed Python modules * find in files * file explorer * project manager * MATLAB-like PYTHONPATH management dialog box (works with all consoles) * Windows only: current user environment variables editor * direct links to documentation (Python, Qt, Matplotlib, NumPy, Scipy, etc.) * direct link to Python(x,y) launcher * direct links to QtDesigner, QtLinguist and QtAssistant (Qt documentation) Bug fixes (since v2.0.6): Consoles/bugfix: saving history log (see context menu) was not working following a recent code cleaning/refactoring On non-Windows platforms, the file selection dialog "All files (*.*)" filter was not matching files without extension dochelpers.isdefined/bugfix: ignoring syntax errors while evaluating object Preferences Dialog (dialog box + keyboard shortcut page): improved size/resize behavior Editor: when cursor was on the very last line, Duplicate/Delete line features were getting stuck in an infinite loop Editor/duplicate line feature - fixed unexpected behavior: when duplicating selected text, text selection was extended to duplicated part Editor/bugfix with multiple editor windows: when opening file on one editor window, the top-left corner menu (file list) was not updated correctly in other editor windows Editor/fixed unexpected behavior: when clicking on the main window's outline explorer while a separate editor window had focus, the latter was used to show the associated line of code Project explorer: added new debugging options (profiling 'rope' calls) Console/Advanced settings/UMD module list: removing all entries (empty module list) was not working Editor/File list management dialog (Ctrl+E): double-clicking/pressing Return on a listwidget item will switch to the associated file Editor/Tab bar: fixed missing tooltips issue (and missing file switch menu entries) Code completion/bugfix: list widget was not hiding as expected when pressing ':' Editor/fixed unexpected behavior: when some text was selected, "Ctrl+Left mouse click" was trying to "go to definition" instead of doing the standard drag n'drop feature Editor/bugfix: disabling code completion/calltips for non-Python source code (was not working -as expected- but was taking time to simply not work...) Editor/go to line: fixed unicode error Code editor/bugfix: cursor position was not restored when undoing an indent operation with "tab always indent" feature turned on *and* the cursor at the end of the line Tab behavior when "tab always indents" is turned off: inserting 4-(len(leading_text) % 4) spaces (instead of 4) Object inspector/bugfix: ignoring unknown objects when called automatically from editor/console, i.e. do not log, do not show 'no doc available' Other changes (since v2.0.6): Code editor syntax highlighting: added more keywords to Cython syntax highlighter (cpdef, inline, cimport and DEF) Added example of application using the Spyder's internal shell as a debugging console (demonstrates also the py2exe deployment procedure) Object inspector: added "Source" combo box (Console/Editor) -> object inspected from editor are now analyzed only with rope (if available) and then shown in object inspector Added keyboard shortcut to open Preferences Dialog (default: Ctrl+Alt+Shift+P) Editor: added "Copy line" feature (Ctrl+Alt+Down), similar to "Duplicate line" (Ctrl+Alt+Up) but paste text before the current line/selected text (instead of after) Array editor: added option to set row/col labels (resp. ylabels and xlabels) Editor/rope: improved performance for calltips/doc feature Cheers, Pierre _______________________________________________ SciPy-User mailing list [hidden email] http://mail.scipy.org/mailman/listinfo/scipy-user |
Thanks for your work Pierre!
Keep Going! Ciao _______________________________________________ SciPy-User mailing list [hidden email] http://mail.scipy.org/mailman/listinfo/scipy-user |
I'd like to echo Davide's sentiment. For those that don't know Spyder (Scientific PYthon Devlopment EnviRonment) is a phenomenal piece of open source scientific software. And if you really want to see the future of scientific computing, check out Pierre's larger endeavor: Python(x,y). Many thanks, Pierre. From: Davide Lasagna <[hidden email]> To: SciPy Users List <[hidden email]> Sent: Sun, February 27, 2011 6:04:49 PM Subject: Re: [SciPy-User] ANN: Spyder v2.0.8 Thanks for your work Pierre! Keep Going! Ciao _______________________________________________ SciPy-User mailing list [hidden email] http://mail.scipy.org/mailman/listinfo/scipy-user _______________________________________________ SciPy-User mailing list [hidden email] http://mail.scipy.org/mailman/listinfo/scipy-user |
In reply to this post by Davide Lasagna
Hi,
is there no option to adjust the indentation width in the Spyder editor? We use two spaces here, not four, so I'd be great to make this an option. I'd be fine with a modification in a config file, thought. Thanks in advance, Daniel _______________________________________________ SciPy-User mailing list [hidden email] http://mail.scipy.org/mailman/listinfo/scipy-user |
On 3/3/11 7:01 AM, Daniel Mader wrote:
> We use two spaces here, not four, so I'd be great to make this > an option. I'd be fine with a modification in a config file, thought. While Python allows many options for indenting (including mixed tabs and spaces!), four spaces is a well established standard -- it really is a good idea to stick with it, especially if you are going to be sharing code with anyone, ever. -CHB -- Christopher Barker, Ph.D. Oceanographer Emergency Response Division NOAA/NOS/OR&R (206) 526-6959 voice 7600 Sand Point Way NE (206) 526-6329 fax Seattle, WA 98115 (206) 526-6317 main reception [hidden email] _______________________________________________ SciPy-User mailing list [hidden email] http://mail.scipy.org/mailman/listinfo/scipy-user |
On 3/3/2011 2:31 PM, Christopher Barker wrote:
> four spaces is a well established standard ... for the standard library. Individual projects set their own standards. (Unfortunately, PEP 8 came down on the wrong side of tabs vs. spaces.) http://stackoverflow.com/questions/120926/why-does-python-pep-8-strongly-recommend-spaces-over-tabs-for-indentation fwiw, Alan Isaac _______________________________________________ SciPy-User mailing list [hidden email] http://mail.scipy.org/mailman/listinfo/scipy-user |
On 3/3/11 12:51 PM, Alan G Isaac wrote:
> On 3/3/2011 2:31 PM, Christopher Barker wrote: >> four spaces is a well established standard > > ... for the standard library. Individual projects > set their own standards. OK -- PEP 8 is only _official_ for the standard library, but if you define "standard" as "the way most people do it", then four spaces is it. > (Unfortunately, PEP 8 came > down on the wrong side of tabs vs. spaces.) clearly debatable, but my point is that it is a good idea for all projects to use the same conventions, and the ONLY one that makes any sense at this point in that context is four spaces. Pythons "there should be only one obvious way to do it" philosophy applies here. -Chris -- Christopher Barker, Ph.D. Oceanographer Emergency Response Division NOAA/NOS/OR&R (206) 526-6959 voice 7600 Sand Point Way NE (206) 526-6329 fax Seattle, WA 98115 (206) 526-6317 main reception [hidden email] _______________________________________________ SciPy-User mailing list [hidden email] http://mail.scipy.org/mailman/listinfo/scipy-user |
Hi,
On Thu, Mar 3, 2011 at 2:39 PM, Christopher Barker <[hidden email]> wrote: > On 3/3/11 12:51 PM, Alan G Isaac wrote: >> On 3/3/2011 2:31 PM, Christopher Barker wrote: >>> four spaces is a well established standard >> >> ... for the standard library. Individual projects >> set their own standards. > > OK -- PEP 8 is only _official_ for the standard library, but if you > define "standard" as "the way most people do it", then four spaces is it. > >> (Unfortunately, PEP 8 came >> down on the wrong side of tabs vs. spaces.) > > clearly debatable, but my point is that it is a good idea for all > projects to use the same conventions, and the ONLY one that makes any > sense at this point in that context is four spaces. > > Pythons "there should be only one obvious way to do it" philosophy > applies here. I enjoyed this blog post: http://www.artima.com/weblogs/viewpost.jsp?thread=74230 reprinted in: http://www.amazon.com/Best-Software-Writing-Selected-Introduced/dp/1590595009 Quote: Premise 1: For any given language, there are one or a few common coding styles. Premise 2: There is not now, nor will there ever be, a programming style whose benefit is significantly greater than any of the common styles. Premise 3: Approximately a gaboozillion cycles are spent on dealing with coding style variations. Premise 4: For any non-trivial project, a common coding style is a good thing. Conclusion: Thinking of all the code in the entire world as a single "project" with a single style, we would get more value than we do by allowing for variations in style. Best, Matthew _______________________________________________ SciPy-User mailing list [hidden email] http://mail.scipy.org/mailman/listinfo/scipy-user |
In reply to this post by Chris Barker - NOAA Federal
On 03-03-2011 23:39, Christopher Barker wrote:
> On 3/3/11 12:51 PM, Alan G Isaac wrote: >> On 3/3/2011 2:31 PM, Christopher Barker wrote: >>> four spaces is a well established standard >> ... for the standard library. Individual projects >> set their own standards. > OK -- PEP 8 is only _official_ for the standard library, but if you > define "standard" as "the way most people do it", then four spaces is it. > >> (Unfortunately, PEP 8 came >> down on the wrong side of tabs vs. spaces.) > clearly debatable, but my point is that it is a good idea for all > projects to use the same conventions, and the ONLY one that makes any > sense at this point in that context is four spaces. but the standard is depending on the environment. Is Python the environment or the set of actually used tools. For me and the people around me, the programs we make, are the environment. We use PHP, Delphi, C, JAL, JS, Matlab, Labview, .... and in all these languages me and my environment uses 2 spaces. So the standard for Python is also 2 spaces. Secondly, the libraries and programs that we put in the open source community, by who will they be (probably) changed and maintained? So it seems to me perfectly legal to use 2 spaces as thé standard. cheers, Stef Mientki > Pythons "there should be only one obvious way to do it" philosophy > applies here. > > -Chris > _______________________________________________ SciPy-User mailing list [hidden email] http://mail.scipy.org/mailman/listinfo/scipy-user |
Guido van Rossum wrote in 2006:
"(...) Fortunately it's easy to separate the two. If it uses two-space indents, it's corporate code; if it uses four-space indents, it's open source. (If it uses tabs, I didn't write it! :-)" http://www.artima.com/weblogs/viewpost.jsp?thread=143947 On 4 Mar, 01:53, Stef Mientki <[hidden email]> wrote: > On 03-03-2011 23:39, Christopher Barker wrote:> On 3/3/11 12:51 PM, Alan G Isaac wrote: > >> On 3/3/2011 2:31 PM, Christopher Barker wrote: > >>> four spaces is a well established standard > >> ... for the standard library. Individual projects > >> set their own standards. > > OK -- PEP 8 is only _official_ for the standard library, but if you > > define "standard" as "the way most people do it", then four spaces is it. > > >> (Unfortunately, PEP 8 came > >> down on the wrong side of tabs vs. spaces.) > > clearly debatable, but my point is that it is a good idea for all > > projects to use the same conventions, and the ONLY one that makes any > > sense at this point in that context is four spaces. > > Using a standard might be a good idea, > but the standard is depending on the environment. > Is Python the environment or the set of actually used tools. > For me and the people around me, > the programs we make, are the environment. > We use PHP, Delphi, C, JAL, JS, Matlab, Labview, .... > and in all these languages me and my environment uses 2 spaces. > So the standard for Python is also 2 spaces. > > Secondly, the libraries and programs that we put in the open source community, > by who will they be (probably) changed and maintained? > So it seems to me perfectly legal to use 2 spaces as thé standard. > > cheers, > Stef Mientki > > > Pythons "there should be only one obvious way to do it" philosophy > > applies here. > > > -Chris > > _______________________________________________ > SciPy-User mailing list > [hidden email]://mail.scipy.org/mailman/listinfo/scipy-user SciPy-User mailing list [hidden email] http://mail.scipy.org/mailman/listinfo/scipy-user |
I would SO love it if Spyder would make that configurable. Honestly :)
I'll open an issue on this, I guess. 2011/3/4 Krystian Rosiński <[hidden email]>: > Guido van Rossum wrote in 2006: > > "(...) Fortunately it's easy to separate the two. If it uses two-space > indents, it's corporate code; if it uses four-space indents, it's open > source. (If it uses tabs, I didn't write it! :-)" > > http://www.artima.com/weblogs/viewpost.jsp?thread=143947 > > On 4 Mar, 01:53, Stef Mientki <[hidden email]> wrote: >> On 03-03-2011 23:39, Christopher Barker wrote:> On 3/3/11 12:51 PM, Alan G Isaac wrote: >> >> On 3/3/2011 2:31 PM, Christopher Barker wrote: >> >>> four spaces is a well established standard >> >> ... for the standard library. Individual projects >> >> set their own standards. >> > OK -- PEP 8 is only _official_ for the standard library, but if you >> > define "standard" as "the way most people do it", then four spaces is it. >> >> >> (Unfortunately, PEP 8 came >> >> down on the wrong side of tabs vs. spaces.) >> > clearly debatable, but my point is that it is a good idea for all >> > projects to use the same conventions, and the ONLY one that makes any >> > sense at this point in that context is four spaces. >> >> Using a standard might be a good idea, >> but the standard is depending on the environment. >> Is Python the environment or the set of actually used tools. >> For me and the people around me, >> the programs we make, are the environment. >> We use PHP, Delphi, C, JAL, JS, Matlab, Labview, .... >> and in all these languages me and my environment uses 2 spaces. >> So the standard for Python is also 2 spaces. >> >> Secondly, the libraries and programs that we put in the open source community, >> by who will they be (probably) changed and maintained? >> So it seems to me perfectly legal to use 2 spaces as thé standard. >> >> cheers, >> Stef Mientki >> >> > Pythons "there should be only one obvious way to do it" philosophy >> > applies here. >> >> > -Chris >> >> _______________________________________________ >> SciPy-User mailing list >> [hidden email]://mail.scipy.org/mailman/listinfo/scipy-user > _______________________________________________ > SciPy-User mailing list > [hidden email] > http://mail.scipy.org/mailman/listinfo/scipy-user > SciPy-User mailing list [hidden email] http://mail.scipy.org/mailman/listinfo/scipy-user |
Free forum by Nabble | Edit this page |