The EP14 Pylint sprint team (more on this here and there) is proud to announce they just released Pylint 1.3 together with its companion Astroid 1.2. As usual, this includes several new features as well and bug fixes. You'll find below some structured list of the changes.

Packages are uploaded to pypi, debian/ubuntu packages should be soon provided by Logilab, until they get into the standard packaging system of your favorite distribution.

Please notice Pylint 1.3 will be the last release branch support python 2.5 and 2.6. Starting from 1.4, we will only support python greater or equal to 2.7. This will be the occasion to do some great cleanup in the code base. Notice this is only about the Pylint's runtime, you should still be able to run Pylint on your Python 2.5 code, through using Python 2.7 at least.

Emit 'undefined-variable' when using the Python 3 metaclass= argument. Also fix 'unused-import' false for that construction (#143)

Emit 'broad-except' and 'bare-except' even if the number of except handlers is different than 1. Fixes issue (#113)

Emit 'attribute-defined-outside-init' for all statements in the same module as the offended class, not just for the last assignment (#262, as well as a long standing output mangling problem in some edge cases)

Emit 'not-callable' when calling properties (#268)

Don't let ImportError propagate from the imports checker, leading to crash in some namespace package related cases (#203)

Claudiu killed maybe 10 bugs or so and did some heavy issues cleanup in the trackers. He also demonstrated some experimental support of python 3 style annotation to drive a better inference. Pretty exciting!
Torsten also killed several bugs, restored python 2.5 compat (though that will need a logilab-common release as well), introduced a new functional test framework that will replace the old one once all the existing tests will be backported. On wednesday, he did show us a near future feature they already have at Google: some kind of confidence level associated to messages so that you can filter out based on that.
Sylvain fixed a couple of bugs (including https://bitbucket.org/logilab/pylint/issue/58/ which was annoying all the numpy community), started some refactoring of the PyLinter class so it does a little bit fewer things (still way too many though) and attempted to improve the pylint note on both pylint and astroid, which went down recently "thanks" to the new checks like 'bad-continuation'.

Also, we merged the pylint-brain project into astroid to simplify things, so you should now submit your brain plugins directly to the astroid project. Hopefuly you'll be redirected there on attempt to use the old (removed) pylint-brain project on bitbucket.

And, the good news is that now both Torsten and Claudiu have new powers: they should be able to do some releases of pylint and astroid. To celebrate that and the end of the sprint, we published Pylint 1.3 together with Astroid 1.2. More on this here.

We've had a fairly enjoyable and productive first day in our little hidden room at EuroPython in Berlin ! Below are some noticeable things we've worked on and discussed about.

First, we discussed and agreed that while we should at some point cut the cord to the logilab.common package, it will take some time notably because of the usage logilab.common.configuration which would be somewhat costly to replace (and is working pretty well). There are some small steps we should do but basically we should mostly get back some pylint/astroid specific things from logilab.common to astroid or pylint. This should be partly done during the sprint, and remaining work will go to tickets in the tracker.

We also discussed about release management. The point is that we should release more often, so every pylint maintainers should be able to do that easily. Sylvain will write some document about the release procedure and ensure access are granted to the pylint and astroid projects on pypi. We shall release pylint 1.3 / astroid 1.2 soon, and those releases branches will be the last one supporting python < 2.7.

During this first day, we also had the opportunity to meet Carl Crowder, the guy behind http://landscape.io, as well as David Halter which is building the Jedi completion library (https://github.com/davidhalter/jedi). Landscape.io runs pylint on thousands of projects, and it would be nice if we could test beta release on some part of this panel. On the other hand, there are probably many code to share with the Jedi library like the parser and ast generation, as well as a static inference engine. That deserves a sprint on his own though, so we agreed that a nice first step would be to build a common library for import resolution without relying on the python interpreter for that, while handling most of the python dark import features like zip/egg import, .pth files and so one. Indeed that may be two nice future collaborations!

Last but not least, we got some actual work done:

Michal Nowikowski from Intel in Poland joined us to work on the ability to run pylint in different processes so it may drastically improve performance on multiple cores box.

Torsten did continue some work on various improvements of the functionnal test framework.

Sylvain did merge logilab.common.modutils module into astroid as it's mostly driven by astroid and pylint needs. Also fixed the annoying namespace package crash.

Claudiu keep up the good work he does daily at improving and fixing pylint :)

Once again, a lot of work has been achieved since the latest 1.1
release. Claudiu, who joined the maintainer team (Torsten and me) did a
great work in the past few months. Also lately Torsten has backported a lot of
things from their internal G[oogle]Pylint. Last but not least, various people contributed by
reporting issues and proposing pull requests. So thanks to everybody!

Notice Pylint 1.2 depends on astroid 1.1 which has been released at the same
time. Currently, code is available on Pypi, and Debian/Ubuntu packages should be ready shortly on Logilab's acceptance repositories.

Below is the changes summary, check the changelog for more info.

New and improved checks:

New message 'eval-used' checking that the builtin function eval was used.

New message 'bad-reversed-sequence' checking that the reversed
builtin receive a sequence (i.e. something that implements __getitem__ and __len__, without being
a dict or a dict subclass) or an instance which implements __reversed__.

New message 'bad-exception-context' checking that raise ... from ... uses a proper exception context (None or an exception).

New message 'abstract-class-instantiated' warning when abstract classes created with abc module and with abstract methods are instantied.

New messages checking for proper class __slots__: 'invalid-slots-object' and 'invalid-slots'.

New message 'undefined-all-variable' if a package's __all__ variable contains a missing submodule (#126).

New option logging-modules giving the list of module names that can be checked for 'logging-not-lazy'.

New option include-naming-hint to show a naming hint for invalid name (#138).

Mark file as a bad function when using python2 (#8).

Add support for enforcing multiple, but consistent name styles for different
name types inside a single module.

Warn about empty docstrings on overridden methods.

Inspect arguments given to constructor calls, and emit relevant warnings.

Extend the number of cases in which logging calls are detected (#182).

Enhance the check for 'used-before-assignment' to look for nonlocal uses.

Improve cyclic import detection in the case of packages.

Bug fixes:

Do not warn about 'return-arg-in-generator' in Python 3.3+.

Do not warn about 'abstract-method' when the abstract method is implemented through assignment (#155).

Do not register most of the 'newstyle' checker warnings with python >= 3.

New option for the multi-statement warning to allow single-line if statements.

Allow to run pylint as a python module 'python -m pylint' (anatoly techtonik).

Various fixes to epylint

Bug fixes:

Avoid false used-before-assignment for except handler defined identifier used
on the same line (#111).

'useless-else-on-loop' not emited if there is a break in the else clause of
inner loop (#117).

Drop 'badly-implemented-container' which caused several problems in its
current implementation.

Don't mark input as a bad function when using python3 (#110).

Use attribute regexp for properties in python3, as in python2

Fix false-positive 'trailing-whitespace' on Windows (#55)

Other:

Replaced regexp based format checker by a more powerful (and nit-picky)
parser, combining 'no-space-after-operator', 'no-space-after-comma' and
'no-space-before-operator' into a new warning 'bad-whitespace'.

Create the PYLINTHOME directory when needed, it might fail and lead to
spurious warnings on import of pylint.config.

Fix setup.py so that pylint properly install on Windows when using python3.

Various documentation fixes and enhancements

Packages will be available in Logilab's Debian and Ubuntu repository in the next few weeks.

Since then, I somewhat continued to use the continuous integration (CI) service we provide on logilab.org to run tests on new commits, and to do the release job (publish a tarball on pypi, on our web site, build Debian and Ubuntu packages, etc.). This is fine, but not really handy since the logilab.org's CI service is not designed to be used for projects hosted elsewhere. Also I wanted to see what others have to offer, so I decided to find a public CI service to host Pylint and Astroid automatic tests at least.

Here are the results of my first swing at it. If you have others suggestions, some configuration proposal or whatever, please comment.

The first one I actually tested, also the first one to show up when looking for "bitbucket continuous integration" on Google is https://drone.io. The UI is really simple, I was able to set up tests for Pylint in a matter of minutes: https://drone.io/bitbucket.org/logilab/pylint. Tests are automatically launched when a new commit is pushed to Pylint's Bitbucket repository and that setup was done automatically.

Trying to push Drone.io further, one missing feature is the ability to have different settings for my project, e.g. to launch tests on all the python flavor officially supported by Pylint (2.5, 2.6, 2.7, 3.2, 3.3, pypy, jython, etc.). Last but not least, the missing killer feature I want is the ability to launch tests on top of Pull Requests, which travis-ci supports.

Then I gave http://wercker.com a shot, but got stuck at the Bitbucket repository selection screen: none were displayed. Maybe because I don't own Pylint's repository, I'm only part of the admin/dev team? Anyway, wercker seems appealing too, though the configuration using yaml looks a bit more complicated than drone.io's, but as I was not able to test it further, there's not much else to say.

So for now the winner is https://drone.io, but the first one allowing me to test on several Python versions and to launch tests on pull requests will be the definitive winner! Bonus points for automating the release process and checking test coverage on pull requests as well.

I'm very pleased to announce, after 10 years of existence, the 1.0 release of Pylint.

This release has a hell long ChangeLog, thanks to many contributions and to the
10th anniversary sprint we hosted during june. More details about changes below.

Chances are high that your Pylint score will go down with this new release that includes a
lot of new checks :) Also, there are a lot of improvments on the Python 3 side
(notably 3.3 support which was somewhat broken).

You may download and install it from Pypi or from Logilab's debian
repositories. Notice Pylint has been updated to use the new Astroid library
(formerly known as logilab-astng) and that the logilab-common 0.60 library
includes some fixes necessary for using Pylint with Python3 as well as
long-awaited support for namespace packages.

New API to make it smarter by allowing transformation functions on any
node, providing a register_transform function on the manager instead of
the register_transformer to make it more flexible wrt node selection

Use this new transformation API to provide support for namedtuple
(actually in pylint-brain, logilab-astng #8766)

Astroid is the new name of former logilab-astng library. It's an AST library,
used as the basis of Pylint and including Python 2.5 -> 3.3 compatible tree
representation, statical type inference and other features useful for advanced
Python code analysis, such as an API to provide extra information when
statistical inference can't overcome Python dynamic nature (see the
pylint-brain project for instance).

It has been renamed and hosted to bitbucket to make clear that this is not a
Logilab dedicated project but a community project that could benefit to any
people manipulating Python code (statistical analysis tools, IDE, browser, etc).

To get started, we took advantage of this last day to have a few discussions about:

A "mode" feature gpylint has. It turns out that behind perhaps a few implementation details, this is something we definitly want into pylint (mode are specific configurations defined in the pylintrc and easilly recallable, they may even be specified per file).

How to avoid conflicts in the ChangeLog by using specific instruction in the commit message. We decided that a commit message should look like

[my checker] do this and that. Closes #1234
bla bla bla
:release note: this will be a new item in the ChangeLog
as well as anything until the end of the message

now someone has to write the ChangeLog generation script so we may use this for post-1.0 releases

Anthony worked on having a template for the text reporter. His patch is available on Bitbucket but not yet integrated.

Julien and David pushed a bunch of patches on logilab-common, astroid and pylint for the Python 3.3 support. Not all tests are green on the pylint side, but much progress was done.

A couple other things were fixed, like a better "invalid name" message, stop complaining about string module being deprecated, etc.

A lot of patches have been integrated, from gpylint and others (e.g python 3 related)

All in all, an impressive amount of work was achieved during this sprint:

A lot of new checks or enhanced behaviour backported from gpylint (Take a look at Pylint's ChangeLog for more details on this, the list is impressively long).

The transformation API of astroid now allows to customize the tree structure as well as the inference process, hence to make pylint smarter than ever.

Better python 3 support.

A few bugs fixed and some enhancements added.

The templating stuff should land with the CLI cleanup (some output-formats will be removed as well as the --include-ids and --symbols option).

A lot of discussions, especially regarding the future community development of pylint/astroid on Bitbucket. Short summary being: more contributors and integrators are welcome! We should drop some note somewhere to describe how we are using bitbucket's pull requests and tracker.

Today was the second day of the 10th anniversary Pylint sprint in Logilab's Toulouse office.

This morning, we started with a presentation by myself about how the inference engine works in astroid (former astng).
Then we started thinking all together about how we should change its API to be able to plug more information during the inference process. The first use-case we wanted to assert was namedtuple, as explained in http://www.logilab.org/ticket/8796.

We ended up by addressing it by:

enhancing the existing transformation feature so one may register a transformation function on any node rather than on a module node only;

being able to specify, on a node instance, a custom inference function to use instead of the default (class) implementation.

We would then be able to customize both the tree structure and the inference process and so to resolve the cases we were targeting.

Once this was sufficiently sketched out, everyone got his own tasks to do. Here is a quick summary of what has been achieved today:

Anthony resumed the check_messages thing and finished it for the simple cases, then he started on having a template for text reported,

Julien and David made a lot of progress on the Python 3.3 compatibility, though not enough to get the full green test suite,

Torsten continued backporting stuff from gpylint, all of them having been integrated by the end of the day,

Sylvain implemented the new transformation API and had the namedtuple proof of concept working, and even some documentation! Now this have to be tested for more real-world uses.

So things are going really well, and see you tomorrow for even more improvements to pylint!

Today was the first day of the Pylint sprint we organized using
Pylint's 10th years anniversary as an excuse.

So I (Sylvain) have welcome my fellow Logilab friends David, Anthony
and Julien as well as Torsten from Google into Logilab's new Toulouse
office.

After a bit of presentation and talk about Pylint development, we
decided to keep discussion for lunch and dinner and to setup
priorities. We ended with the following tasks (picks from the pad at
http://piratepad.net/oAvsUoGCAC):

rename astng to move it outside the logilab package,

Torsten gpylint (Google Pylint) patches review, as much as
possible (but not all of them, starting by a review of the numberous
internal checks Google has, seeing one by one which one should be
backported upstream),

In the afternoon, David and Julien tackled this, while Torsten was
extracting patches from Google code and sending them to bitbucket as
pulll request, Sylvain embrassing setuptools namespaces packages and
Anthony discovering the code to spread the @check_message decorator
usage.

Torsten submitted 5 pull-requests with code extracted from gpylint,
we reviewed them together and then Torsten used evolve to properly
insert those in the pylint history once review comments were
integrated

Sylvain submitted 2 patches on logilab-common to support both
setuptools namespace packages and pkgutil.extend_path (but
not bare __path__ manipulation

Anthony discovered various checkers and started adding proper
@check_messages on visit methods

After doing some review all together, we even had some time to take a
look at Python 3.3 support while writing this summary.

Hopefuly, our work on forthcoming days will be as efficient as on this first day!

After 10 years of hosting Pylint on our own forge at logilab.org, we've decided to publish version 1.0 and move Pylint and astng development to BitBucket. There has been repository mirrors there for some time, but we intend now to use all BitBucket features, notably Pull Request, to handle various development tasks.

There are several reasons behind this. First, using both BitBucket and our own forge is rather cumbersome, for integrators at least. This is mainly because BitBucket doesn't provide support for Mercurial's changeset evolution feature while our forge relies on it. Second, our forge has several usability drawbacks that make it hard to use for newcomers, and we lack the time to be responsive on this. Finally, we think that our quality-control process, as exposed by our forge, is a bit heavy for such community projects and may keep potential contributors away.

All in all, we hope this will help to have a wider contributor audience as well as more regular maintainers / integrators which are not Logilab employees. And so, bring the best Pylint possible to the Python community!

Logilab.org web pages will be updated to mention this, but kept as there is still valuable information there (eg tickets). We may also keep automatic tests and package building services there.

So, please use https://bitbucket.org/logilab/pylint as main web site regarding pylint development. Bug reports, feature requests as well as contributions should be done there. The same move will be done for Pylint's underlying library, logilab-astng (https://bitbucket.org/logilab/astng). We also wish in this process to move it out of the 'logilab' python package. It may be a good time to give it another name, if you have any idea don't hesitate to express yourself.

In a few week, pylint will be 10 years old (0.1 released on may 19 2003!).
At this occasion, I would like to release a 1.0. Well, not exactly at that date,
but not too long after would be great. Also, I think it would be a good time
to have a few days sprint to work a bit on this 1.0 but also to meet all together
and talk about pylint status and future, as more and more contributions come from
outside Logilab (actually mostly Google, which employs Torsten and Martin, the most
active contributors recently).

The first thing to do is to decide a date and place. Having discussed a bit with
Torsten about that, it seems reasonable to target a sprint during june or july.
Due to personal constraints, I would like to host this sprint in Logilab's
Toulouse office.

So, who would like to jump in and sprint to make pylint even better? I've created
a doodle so every one interested may tell his preferences:
http://doodle.com/4uhk26zryis5x7as

Regarding the location, is everybody ok with Toulouse? Other ideas are Paris, or
Florence around EuroPython, or... <add your proposition here>.

We'll talk about the sprint topics later, but there are plenty of exciting ideas
around there.

Please, answer quickly so we can move on. And I hope to see you all there!

I'm very pleased to announce the release of pylint 0.27 and
logilab-astng 0.24.2. There has been a lot of enhancements and
bug fixes since the latest release, so you're strongly encouraged
to upgrade. Here is a detailed list of changes:

I'm very pleased to announce new releases of Pylint and
underlying ASTNG library, respectivly 0.26 and 0.24.1. The great
news is that both bring a lot of new features and some bug fixes,
mostly provided by the community effort.

We're still trying to make it easier to contribute on our free
software project at Logilab, so I hope this will continue and
we'll get even more contritions in a near future, and an even
smarter/faster/whatever pylint!

PyLint should now work with alternative python implementations such as Jython, and at least go further with PyPy and IronPython (but those have not really been tested, please try it and provide feedback so we can improve their support)

Huum, along with the new PyLint release, it's time to introduce the PyLint-Brain project I've recently started.

Despite its name, PyLint-Brain is actually a collection of extensions for ASTNG, with the goal of making ASTNG smarter (and this directly benefits PyLint) by describing stuff that is too dynamic to be understood automatically (such as functions in the hashlib module, defaultdict, etc.).

The PyLint-Brain collection of extensions is developped outside of ASTNG itself and hosted on a bitbucket project to ease community involvement and to allow distinct development cycles. Basically, ASTNG will include the PyLint-Brain extensions, but you may use earlier/custom versions by tweaking your PYTHONPATH.

Take a look at the code, it's fairly easy to contribute new descriptions, and help us make pylint smarter!

The latest release of logilab-astng (0.23), the underlying source code
representation library used by PyLint, provides a new API that may change pylint users' life in the near future...

It aims to allow registration of functions that will be called after a module has
been parsed. While this sounds dumb, it gives a chance to fix/enhance the
understanding PyLint has about your code.

I see this as a major step towards greatly enhanced code analysis, improving the
situation where PyLint users know that when running it against code using their
favorite framework (who said CubicWeb? :p ), they should expect a bunch of false
positives because of black magic in the ORM or in decorators or whatever else. There are also places in the Python standard library where dynamic code can cause false positives in PyLint.

The code runs fine... Why does pylint bother me then? If we take a look at the
hashlib module, we see that there are no sha1 or md5 defined in
there. They are defined dynamically according to Openssl library availability in order to use the fastest available implementation, using code like:

for __func_name in __always_supported:
# try them all, some may not work due to the OpenSSL
# version not supporting that algorithm.
try:
globals()[__func_name] = __get_hash(__func_name)
except ValueError:
import logging
logging.exception('code for hash %s was not found.', __func_name)

Honestly I don't blame PyLint for not understanding this kind of magic. The
situation on this particular case could be improved, but that's some tedious
work, and there will always be "similar but different" case that won't be
understood.

A function that will be called with each astng module built during a pylint
execution, i.e. not only the one that you analyses, but also those accessed for
type inference.

This transformation function is fairly simple: if the module is the 'hashlib'
module, it will insert into its locals dictionary a fake class node for each
desired name.

It is registered using the register_transformer method of astng's MANAGER
(the central access point to built syntax tree). This is done in the pylint
plugin API register callback function (called when module is imported using
'pylint --load-plugins'.

Now let's try it! Suppose I stored the above code in a 'astng_hashlib.py' module in my
PYTHONPATH, I can now run pylint with the plugin activated:

Huum. We have now a different error :( Pylint grasp there are some md5 and
sha1 classes but it complains they don't have a hexdigest method. Indeed,
we didn't give a clue about that.

We could continue on and on to give it a full representation of hashlib public
API using the astng nodes API. But that would be painful, trust me. Or we could
do something clever using some higher level astng API:

The idea is to write a fake python implementation only documenting the prototype
of the desired class, and to get an astng from it, using the string_build method of
the astng builder. This method will return a Module node containing the astng
for the given string. It's then easy to replace or insert additional information
into the original module, as you can see in the above example.

This fairly simple change could quickly provide great enhancements. We should
probably improve the astng manipulation API now that it's exposed like
that. But we can also easily imagine a code base of such pylint plugins
maintained by each community around a python library or framework. One could
then use a plugins stack matching stuff used by its software, and have a greatly
enhanced experience of using pylint.

For a start, it would be great if pylint could be shipped with a plugin that
explains all the magic found in the standard library, wouldn't it? Left as an exercice to
the reader!

Those releases include mostly fixes and a few enhancements. Python 2.6
relative / absolute imports should now work fine and Python 3 support
has been enhanced. There are still two remaining failures in astng
test suite when using python 3, but we're unfortunatly missing
resources to fix them yet.

Many thanks to everyone who contributed to this release by submitting
patches or by participating to the latest bugs day.

I know the announce is a bit late, but I hope some of you will be able to come or be online anyway!

Regarding the program, the goal is to decrease the number of tickets in the tracker. I'll try to do some triage earlier this week so you'll get a chance to talk about your super-important ticket that has not been selected. Of course, if you intend to work on it, there is a bigger chance of it being fixed next week-end ;)

First of all, I've to say that pylint bugs day wasn't that successful in term of 'community event': I've been sprinting almost alone. My Logilab's felows were tied to customer projects, and no outside people shown up on jabber. Fortunatly Tarek Ziade came to visit us, and that was a nice opportunity to talk about pylint, distribute, etc ... Thank you Tarek, you saved my day ;)

As I felt a bit alone, I decided to work on somethings funnier than bug fixing: refactoring!

First, I've greatly simplified the command line: enable-msg/enable-msg-cat/enable-checker/enable-report and their disable-* counterparts were all merged into single --enable/--disable options.

I've also simplified "pylint --help" output, providing a --long-help option to get what we had before. Generic support in `logilab.common.configuration of course.

And last but not least, I refactored pylint so we can have multiple checkers with the same name. The idea behind this is that we can split checker into smaller chunks, basically
only responsible for one or a few related messages. When pylint runs, it only uses necessary checkers according to activated messages and reports. When all checkers will be splitted, it should improve performance of "pylint --error-only".

So, I can say I'm finally happy with the results of that pylint bugs day! And hopefuly we will be more people for the next edition...

Remember that the first pylint bug day will be held on wednesday, november 25, from around 8am to 8pm in the Paris (France) time zone.

We'll be a few people at Logilab and hopefuly a lot of other guys all around the world, trying to make pylint better.

Join us on the #public conference room of conference.jabber.logilab.org, or if you prefer using an IRC client, join #public on irc.logilab.org which is a gateway to the jabber forum. And if you're in Paris, come to work with us in our office.

People willing to help but without knowledge of pylint internals are welcome, it's the perfect occasion to learn a lot about it, and to be able to hack on pylint in the future!

Since we don't stop being overloaded here at Logilab, and we've got some encouraging feedback after the "Pylint needs you" post, we decided to take some time to introduce more "community" in pylint.

And the easiest thing to do, rather sooner than later, is a irc/jabber synchronized bug day, which will be held on Wednesday november 25. We're based in France, so main developpers will be there between around 8am and 19pm UTC+1.
If a few of you guys are around Paris at this time and wish to come at Logilab to sprint with us, contact us and we'll try to make this possible.

After several months with no time to fix/enhance pylint beside answering email and filing tickets, I've finally tackled some tasks yesterday night to publish bug fixes releases ([1] and [2]).

The problem is that we don't have enough free time at Logilab to lower the number of tickets in pylint tracker page .
If you take a look at the ticket tab, you'll see a lot of pendings bug and must-have features (well, and some other less necessary...).
You can already easily contribute thanks to the great mercurial dvcs, and some of you do, either by providing patches or by reporting bugs (more tickets, iiirk ! ;) Thank you all btw !!

Now I was wondering what could be done to make pylint going further, and the first ideas which came to my mind was :

do ~3 days sprint

do some 'tickets killing' days, as done in some popular oss projects

But for this to be useful, we need your support, so here are some questions for you:

would you come to a sprint at Logilab (in Paris, France), so you can meet us, learn a lot about pylint, and work on tickets you wish to have in pylint?

if France is too far away for most people, would you have another location to propose?

would you be on jabber for a tickets killing day, providing it's ok with your agenda? if so, what's your knowledge of pylint/astng internals?

you may answer by adding a comment to this blog (please register first by using the link at the top right of this page) or by mail to sylvain.thenault@logilab.fr. If we've enough positive answers, we'll take the time to organize such a thing.

You'll find in the logilab.common.decorators module the iclassmethod decorator which may be pretty handy in some cases as it allows methods to be both called as class methods or as instance methods. In the first case the first argument will be the class and the second case it will be the instance.

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 !

Here is a piece of code I've written which I thought may be useful to some other people...

You'll find here a simple python module to use with the Google AppEngine SDK to monkey patch the datastore API in order to get an idea of the calls performed by your application.

To instrument of the datastore, put at the top level of your handler file

import instrdatastore

Note that it's important to have this before any other import in your application or in the google package to avoid that some modules will use the unpatched version of datastore functions (and hence calls to those functions wouldn't be considered).

I'll probably extend this as the time goes. Also notice you may encounter some problems with the automatic reloading feature of the dev app server when instrumentation is activated, in which case you should simply restart the web server.