Pydev 1.3.15 released (new interactive console)

The major highlight in this release is the new interactive console. Details on it can be found at: http://pydev.sourceforge.net/console.html.

Pydev extensions also has some pluses regarding the interactive console (see: http://fabioz.com/pydev)

I'll do a video showing it in more details shortly (probably over the weekend).

This release also has some other nice things, such as having the regular console accepting unicode chars that are not in the ascii range (it uses the sitecustomize.py feature from python to set the correct encoding to be used in the shell) and other bugfixes.

Get it while it's fresh :)

Interactive console in Pydev

Last week I started working on an interactive console and bundling it into pydev. Hopefully it'll be finished soon (probably within the next 1-2 weeks).

The main structure is already in place... code-completion, context info on hover, history (up/down arrow), colors for stdout/err/prompt/user input, auto-indent, python/jython support, it's all there already... (but I want to add an extra layer of polishment before releasing it).

Under the hood, it's almost like a whole new editor covering the console, while communicating through sockets with a python shell (but it feels a lot like a regular editor, in the sense that the same options that are used in the editor for indent, code completion, etc. are also available from the console -- with the exception that you can actually only edit the active line).

Also, this time I was able to get some code that had an initial draft of a console from dltk (which was pretty nice), but I had to do some (not so minor) changes to be able to add it to pydev, although the basic structure still has the same idea (the result can be seen at org.python.pydev/src_dltk_console).

Well, to sum it up... this is a long-awaited feature, and the plans are for surpassing all expectations on that :)

Pydev 1.3.14

Pydev 1.3.14 is out!

It's mostly a bugfix release with some of niceties:

* In pydev extensions, configuring the remote debugger in a different machine is now easier: mostly setting the constant in pydevd_file_utils.py (in the remote machine being debugged -- see the comments on the file).

* In pydev, having a speed up from using psyco was really nice!

* The improvements in the outline view (by Laurent Dore) and having a more reliable Go to Next/Previous method (Ctrl+Shift+Up/Down) are also pretty nice :)

Pydev debugger and psyco speedups (target: 1.3.14)

The pydev debugger can now make use of psyco if it's available in the environment (it's actually highly recommended... in tests a 50% improvement in the debugger speed was observed... mainly, all the tracing goes through 2 functions, so, speeding it was pretty straightforward -- after discovering how to integrate it).

Now, this relation is kind of strange: the pydev debugger can make use of psyco, but the debugged code can't (because if it gets compiled, pydev can't trace it).

Until now, a Null() object was added as a psyco module in sys.modules so that clients didn't worry about it, but that had some nasty side effects, so, this version will also change this integration so that clients that rely on psyco don't have to change code: a stub module will replace the psyco module in sys.modules and will mimic it better -- and it'll be installed only after pydev finishes using it to get its optimizations.

Pydev 1.3.12: bug in outline

The release has been out for some days now, but there's one bug in that release I think is worth mentioning: the outline is not behaving as it should: the actions are not there and it doesn't link with the editor.

This is already fixed in the cvs and will be released next week in a bugfix release...

Nice tip: Always remember to check if a weak-reference is still alive before trying to access it -- this specific portion of the code hasn't been changed in a while, but after changing other things this bug started to show...

Ain't it amazing how software works? I wonder if this kind of thing will be a thing of the past at some point in the future...

Testing for common situations and expanding those tests as bugs are found seems to be the best alternative (currently) -- this is a good feature on dynamic languages: you're never left thinking that if it compiles it works... that's never true anyways -- but it would be nice if there was a better way to ensure things work :)

I guess code-analysis helps there, but it is surely not foolproof... and the number of false positives must also be taken into account: that's one of the reasons why 'self' access check has not been added to pydev extensions: the number of false positives in some sample programs was showing that it was too common to access attributes that the code-analysis couldn't get.

If you think in the dynamic world, code-analysis is also more limited (as there's less info to work on)... The pydev extensions code-analysis helps while you're programming in the same way that a compiler would help you catch stupid errors... and having it does not ensure the program will work anyways (although I think it makes life much more pleasant!... I can't even imagine myself programming in python without having those errors gotten by the code-analysis... the code-run cycle is much slower without it, mostly because the run part ends up acting as the code-analysis -- which should have happened in the code part).

And you know... after you know the reason for the bug it is usually easy fixing it. The hard part is always discovering the bug (which is what we try to tackle with tests, code-analysis, code-reviews... ... ... )!