One point was missing from the presentation and I'll take the opportunity now to mention it. Flymake, an on-the-fly syntax checker for GNU Emacs which has been discussed, does work in combination with Pylint (please see EmacsWiki for more informations).
Logilab.org - en
News from Logilab and our Free Software projects, as well as on topics dear to our hearts (Python, Debian, Linux, the semantic web, scientific computing...)
I'm pleased to announce releases of pylint 0.18, logilab-astng 0.19 and logilab-common 0.39. All these packages should now be cleanly available through easy install.
Also, happy pylint users will get:
- fixed python 2.6 support (pylint/astng tested from 2.4 to 2.6)
- get source code (and so astng) for zip/egg imports
- some understanding of the property decorator and of unbound methods
- some false positives fixed and others minor improvments
See projects home page and ChangeLog for more information:
Please report any problem / question to the firstname.lastname@example.org mailing-list.
I recently understood why easy_install wasn't able to find so many of our packages anymore.
The problem was due to a recent change on our website. The project page was ajaxified, and since easy_install uses some screenscrapping techniques to get distribution archives, it can not find the files it is looking for.
To fix this, we should make our tarballs downloadable from PyPI, by using
python setup.py register sdist upload
instead of the current:
python setup.py register
Uploading our public python software packages to PyPI will make them easy_installable in a breeze !
Python 2.5 introduces a new module _ast for Abstract Syntax Tree (AST) representation of python code. This module is quite faster than the compiler.ast representation that logilab-astng (and therefore pylint) used until now and the compiler module was removed in Python 3.0.
Faster is good, but the representations of python code are quite different in _ast and in compiler : some nodes exist in one AST but not the other and almost all child nodes have different names.
We had to engage in a big refactoring to use the new _ast module, since we wanted to stay compatible with python version < 2.5, which meant keeping the compiler module support. A lot of work was done to find a common representation for the two different trees. In most cases we used _ast-like representations and names, but in some cases we kept ideas or attribute names of compiler.
Let's look at an example to compare both representations. Here is a seamingly harmless snippet of code:
CODE = """ if cond: del delvar elif next: print """
Now, compare the respective _ast and compiler representations (nodes are in upper case and their attributes are in lower case).
Module node = Stmt nodes = [ If tests = [ Name name = 'cond' Stmt nodes = [ AssName flags = 'OP_DELETE' name = 'delvar' ] Name name = 'next' Stmt nodes = [ Printnl ] ]
Module body = [ If test = Name id = 'cond' body = [ Delete targets = [ Name id = 'delvar' ] ] orelse = [ If test = Name id = 'next' body = [ Print nl = True ] ] ]
Can you spot any differences? I would say, they differ quite a lot... For instance, compiler turns a "elif" statements into a list called 'tests' when _ast treats "elif cond:" as if it were "else:if cond:".
We transform these trees by renaming attributes and nodes, or removing or introducing new ones: with compiler, we remove the Stmt node, introduce a Delete node, and recursively build the If nodes coming from an "elif"; and with _ast, we reintroduce the AssName node. This might be only a temporary step towards full _ast like representation.
This is done by the TreeRebuilder Visitors, one for each representation, which are respectively in astng._nodes_compiler and astng._ast.
In the simplest case, the TreeRebuilder method looks like this (_nodes_compiler):
def visit_list(self, node): node.elts = node.nodes del node.nodes
(and nothing to do for _ast).
So, after doing all this and a lot more, we get the following representation from both input trees:
Module() body = [ If() test = Name(cond) body = [ Delete() targets = [ DelName(delvar) ] ] orelse = [ If() test = Name(next) body = [ Print() dest = None values = [ ] ] orelse = [ ] ] ]
Of course, you can imagine these modifications had some API repercussions, and thus required a lot of smaller Pylint modifications. But all was done so that you should see no difference in Pylint's behavior using either python <2.5 or python >=2.5, except that with the _ast module pylint is around two times faster!
Oh, and we fixed small bugs on the way and maybe introduced a few new ones...
Finally, it is a major step towards Pylint Py3k!
- Change the search behavior: the button "Next" will move the focus on the next found searched text.
- Diff works on the merge node.
- The command --version shows the current version of hgview
- Fix a bug when the file's name contains space.
Projman is a project management tool. It reads project descriptions and activity logs to schedule tasks and to generate gantt diagrams.
The version 0.13.6 fix some gantt diagram generation bugs. Graphics library helper is now Cairo instead of matplotlib. Some examples, according to the new model (use of resources type and roles in tasks) have been added to the project.
And, of course, the compulsory screenshot.
Being big fans of debian, we are impatiently awaiting the new stable release of the distribution : lenny. Finding it pretty difficult to find information about when they were expecting to release it, I asked a colleague if he knew. He's a debian developer so I though he might have the info. And he did : according to the debian.devel mailing list we should be having the release for the 14th of February 2009. In other words : in 5 days!
There's a few geeky emails on the release date if you have time to read the threads.
We've just released a new project on logilab.org : lutin77. It's a test framework for Fortran77.
The goal of this framework is to make unit tests in fortran 77 by having few dependencies: a POSIX environment with C and fortran 77 compilers. Of course, you can use it for making integration or acceptance tests too. The 0.1 version has just been released here: http://www.logilab.org/project/lutin77
If you are new to the unit tests way of building software, I must admit it lacks examples. For an introduction to the techniques involved, you can have a look at Growing Object-Oriented Software, Guided by Tests even if mocked subroutines will be for later. But remember that if you do not like to write tests, you are probably not writing unit tests.
The version convention that we use is pretty straight forward and standard : it's composed of 3 numbers separated by dots. What are the rules to incrementing each on of these numbers ?
- The last number is a incremented when bugs are corrected
- The middle number is incremented when stories (functionalities) are implemented to the software
- The first number is incremented when we have a major change of technology
Well... if you've been paying attention, apycot just turned 1.0.0, the major change of technology is that it is now integrated to CubicWeb (instead of just generating html files). So for a project in your forge, you describe the apycot configuration for it, and the tests for quality assurance are launched on a regular basis. We're still in the process of stabilizing it (latest right now it 1.0.5), but it already runs on the CubicWeb projects, see the screenshot below :
You should also know that now apycot has two components : the apycotbot which runs the tests and an cubicweb-apycot which displays the results in cubicweb (download cubicweb-apycot-1.0.5.tar.gz and apycotbot-1.0.5.tar.gz).
We've always been big fans of debian here at Logilab. So publishing debian packages for our open source software has always been a priority.
We're now a bit involved with Ubuntu, work with it on some client projects, have a few Ubuntu machines lying around, and we like it too. So we've decided to publish our packages for Ubuntu as well as for debian.
In the 0.12.1 version of logilab-devtools we introduced publishing of Ubuntu packages with lgp (Logilab Packaging) - see ticket. Since then, you can add the following Ubuntu source to your Ubuntu system
deb http://ftp.logilab.org/dists hardy/
For now, only hardy is up and running, give us a shout if you want something else!