Tuesday, October 06, 2015

PyDev 4.4.0 released

PyDev 4.4.0 is now available for download

The main changes in this release include:

  • Improved PyDev Package Explorer to give more information when all elements are filtered -- it seems it was common for new users to end up in a state where there was no working set selected while having a working set filter...
  • Code completion improvements: when a parameter is typed in the docstring, assigning it to an instance gives proper code-completion results when accessing the instance.
  • Fixed issues dealing with ansi colors in the interactive console.
  • When autopep8 is applied as the code formatting engine, the region selected is used to specify the lines for formatting.
  • Minor improvements in the debugger.
For those using LiClipse, there's a critical fix dealing with TextMate/SublimeText bundles (and PyDev has also been upgraded), so, please upgrade...

Thursday, August 20, 2015

PyDev 4.3.0 (improved searching)

PyDev 4.3.0 is out now ;)

The main focus on this release was on ironing out the new search dialog (which makes searching even huge codebases almost instant).

Also, there was a high-priority fix which made the Python 3.x parser accept async and await as regular names and not only keywords.

LiClipse 4.3.0, which had several enhancements in its parsing structure to make the editor even faster was also released to include the new PyDev version.

And as always, thank you very much to the PyDev supporters which help on keeping the PyDev development going strong.

Tuesday, July 07, 2015

PyDev 4.2.0 released (improved searching and type inference)

PyDev 4.2.0 is out now.

This release improves the Python search capabilities to use Lucene indexes, which makes the searching faster.

This also means that actions which depend on searches such as the search for references (Ctrl + Shift + G) and hierarchy view (F4) became much faster as a result.

Also, the searches now have an improved results page which allows matches to be flattened and grouped by project, folders and modules. Also, the results page now allows additional filtering based on the module name.

As a note, LiClipse 2.2.0, also supports Lucene based searching now, adding support for searching other languages.

Also, this release continues on the path of improving code-completion when unpacking compound types (such as dicts, tuples, sets...), which should be really good now (but if I still missed some use-case, please report it to https://sw-brainwy.rhcloud.com/tracker/PyDev/).

This release also includes some bug-fixes, including a critical issue (which affected Linux users) which could lead to high CPU usage when using the vertical indent guides (see http://pydev.org for more information on the bug-fixes).

To finish, a special thanks to all the PyDev supporters (it definitely wouldn't be possible to keep PyDev going without your help -- for those that want to help supporting it, please access the related links at http://pydev.org).

Thursday, June 04, 2015

mu-repo 1.1.1 (cloning multiple git repositories)

One tool I use daily for my git workflows (which are almost always composed of several git repositories) is mu-repo (which is a tool written in Python for dealing with multiple git repositories), so, I'm happy to announce that version 1.1.1 has just been released with a workflow which allows cloning multiple git repositories.

See: http://fabioz.github.io/mu-repo/cloning/ for details.

Also, given that it's gaining some traction recently, I decided to spend some time to actually do a homepage for it to help newcomers (the README on Github was becoming too big already):


As a note, I believe even long time users may benefit from taking a quick look at the Tips & Tricks section ;)

p.s.: mu-repo can now be installed through pip: pip install mu-repo.

p.s.2: Kudos to http://www.mkdocs.org for providing a nice tool to build a homepage from Markdown docs :)

Wednesday, May 27, 2015

PyDev 4.1.0 (code completion improvements, Python 3.5 grammar)

Ok, PyDev 4.1.0 is out now.

Improvements in this release include supporting more use cases when unpacking lists/tuples/sets -- this is the current focus in PyDev right now: making its type inference/code-completion best in class ;)

Also, the new constructs on Python 3.5 are already supported in PyDev in its Python 3 grammar (i.e.: async/await, and @ matrix multiplication).

Another nice feature added in this release is that it's possible to select constructs to be folded by default when an editor is opened (as the image below shows):

Thursday, April 23, 2015

Wrapping docstrings/comments in PyDev

This is a nifty trick when working with PyDev...

When you're writing docstrings it's usually pretty annoying having to manually wrap the contents of the string to fix inside a proper number of columns: say your standard is 80 columns and you've just written 5 lines of comments to fit in that, then, you decide to edit and add something in the middle: there it goes: you have to reindent all the lines below so that the block is nice again.

Well, PyDev has an utility for that: put your cursor on that block and do Ctrl+2, W (i.e.: press Ctrl+2 and type the char W later on). Doing that will fix your comment block to fit in the number of columns available (note that it works for code in docstrings and comments alike).

To give an example, say you have the code below:

Just place the cursor in the block, use Ctrl+2, W and voila, you get:

Hope PyDev users enjoy the trick (aligning those manually is definitely on the annoying group).

As a note, to configure the number of columns to be wrapped to go to preferences > general > editors > text editors and change the 'print margin column'.

To finish, Ctrl+2 has other interesting things (if you just press Ctrl+2 and wait a bit, a popup with the options will appear).

Tuesday, April 21, 2015

Type hinting on Python

If you missed it, it seems right now there's a long thread going on related to the type-hinting PEP:


It seems there's a lot of debate and I think the outcome will shape how Python code will look some years from now, so, I thought I'd give one more opinion to juice things up :)

The main thing going for the proposal is getting errors earlier by doing type-checking (which I find a bit odd in the Python world with duck-typing, when many times a docstring could say it's expecting a list but I could pass a list-like object and could get fine with it).

The main point raised against it is is that with the current proposal, the code becomes harder to read.


def zipmap(f: Callable[[int, int], int], xx: List[int], yy: List[int]) -> List[Tuple[int, int, int]]:

Sure, IDEs -- such as PyDev :) --  will probably have to improve their syntax highlighting so that you could distinguish things better, but I agree that this format is considerably less readable. Note that Python 3 already has the syntax in-place but currently it seems it's very seldomly used -- http://mypy-lang.org/ seems to be the exception :)

Now, for me personally, the current status quo in this regard is reasonable: Python doesn't go into java nor c++ land and keeps working with duck-typing, and Python code can still be documented so that clients knows what kinds of objects are expected as parameters.

I.e.: the code above would be:

def zipmap(f, xx, yy):
    :type f: callable(tuple(int, int))->int
    :type xx: list(int)
    :type yy: list(int)
    :rtype: list(tuple(int, int, int))

Many IDEs can already understand that and give you proper code-completion from that -- at least I know PyDev does :)

The only downside which I see in the current status quo is that the format of the docstrings isn't standardized and there's no static check for it (if you want to opt-in the type-checking world), but both are fixable: standardize it (there could be a grammar for docstrings which define types) and have a tool which parses the docstrings and does runtime checks (using the profiler hook for that shouldn't be that hard... and the overhead should be within reasonable limits -- if you're doing type checking with types from annotations, it should have a comparable overhead anyways).

Personally, I think that this approach has the same benefits without the argument against it (which is a harder to read syntax)...

If more people share this view of the Python world, I may even try to write a runtime type-checking tool based on docstrings in the future :)