GSOC 2012 - Week 10

Tenth week of work of GSOC, after the release of pylint last week, I focused my work on logilab-astng and especially on the two tickets marked as “important”. They both appears only with Python-3k

Ticket 83138

This ticket is based on a new feature of python-3k, starred expression in tuple unpacking. Example:

*a, b = [1, 2, 3]

The correction has been quite simple, we change the Starred node to make it valid as an assignment destination. If you see another problems with Starred expression in tuple unpacking or want to show specific message, don’t hesitate to create a ticket or leave a comment.

Ticket 83749

This second ticket has been more difficult to fix. It gave me more challenge than other and the discovery of the bug is quite funny, so I will detail the process of fixing.

First, as pylint doesn’t complain with Python-2, I first search in the ASTNG (Abstract Syntax Tree New Generation, a more evolved syntax tree) what nodes are different. No encouraging result, same nodes, same tree.

Then, I went outside for a break, it’s amazing how thinking about something else can solve our problems magically.

Let’s try it again, so let’s see this traceback one more time. Hey, the code shown in traceback is not the same:

# Traceback
File "/usr/lib64/python3.2/site-packages/logilab/astng/node_classes.py", line 42, in unpack_infer
infered = next(stmt.infer(context))

# Source code

infered = stmt.infer(context).next()

What’s the problem? Ah, 2to3 is run automatically on installation, OK. But why does it run with python 2, let’s check the Yes node class:

class _Yes(object):
    """a yes object"""
    def __repr__(self):
        return 'YES'
    def __getattribute__(self, name):
        if name.startswith('__') and name.endswith('__'):
            # to avoid inspection pb
            return super(_Yes, self).__getattribute__(name)
        return self
    def __call__(self, *args, **kwargs):
        return self


YES = _Yes()

So, it’s normal, the next() call is intercepted by __getattribute__, not cool. So it’s easy, let’s make the Yes class iterable.

Not so easy, the YES node is not supposed to be in the tree. Where does it come?

When we try to import PickleError from nonexistent, a call to the infer method of this From node will be made by unpack_infer. inference.infer_from will try to import this module, which will fail and raise an InferenceException (by mixins.do_import_module). The infer_name will catch this exception and yield an YES node instead.

The solution is then to not raise an InferenceException on bad import or to not yield an YES node, as my knowledge of pylint internals is limited, I let one pylint master fix it.

Having some challenging tasks and be able to fix it, or almost, is great because it means that we have some understanding of the project and it’s gratifying.

See you next week for new adventures.