[Cython] Beginner-friendly tickets

[Dag Sverre Seljebotn]

Kurt Smith wrote:
> On Wed, Mar 11, 2009 at 4:27 AM, Dag Sverre Seljebotn
> <dagss at student.matnat.uio.no> wrote:
>> Since there's been some interest in how to get started coding on Cython
>> on the mailing list lately, I thought I'd call attention to these two
>> tickets:
>>
>> http://trac.cython.org/cython_trac/ticket/158
>> http://trac.cython.org/cython_trac/ticket/203
>>
>> These seems to fit the sweet spot of not being too hard to fix for
>> beginners (with some mentoring), but not being completely trivial either.
>>
>> I'm happy to provide an attack strategy/small amount of mentoring for
>> these tickets if anybody's interested.
> 
> Hi Dag,
> 
> I'm interested in working on #158 if it isn't already claimed.

Nice! I haven't heard anything on #158 yet, so consider it yours. I've 
assigned both tickets now in trac.

You may want to get Trac accounts if you haven't already BTW, send an 
.htpasswd-file to Robert for that.

> One solution (as mentioned in the ticket comments) would be to raise a
> compilation error since the s variable is declared after it's used.  I
> imagine some checks would be in order to ensure this, but I don't have
> ideas about where to start.

Yep, that's the solution I'm thinking about.

The Cython "parse tree" is processed in stages. Two of those are 
analyse_declarations and analyse_expressions. The problem here is that 
"cdef str s" is handled in the analyse_declarations step and then 
disappears; while the analyse_expressions happen afterwards, and cannot 
know at which point in the source the declaration happened.

So the analyse declarations phase must do this check.

You will need to do your work in AnalyseDeclarationsTransform, in 
ParseTreeTransforms.py. It is a "filter" on the parse tree, and each 
method is called as you go according to the type of the node. Read some 
of the different transforms in that file to get the idea (to see the 
parse tree, insert e.g. "print node.dump()" at the beginning of 
visit_ModuleNode).

Now:

a) Keep a dict in self containing the names that has been referenced up 
to that point in the given scope (i.e. in visit_ModuleNode and 
visit_FuncDefNode you need to push/pop which dict one is using 
before/after processing the contents).

b) Everywhere a name is used, a NameNode sits in the parse tree. So you 
create a visit_NameNode to record that the variable was used (it doesn't 
really matter whether it was assigned to or read; any usage of the 
variable before a cdef should be illegal).

c) Finally, in visit_CVarDefNode you can now check whether the name has 
already been seen in the module/function, and if so there's a problem 
and you raise an exception (see other transforms for the convention here).

Please ask again if/when you get stuck or anything was too brief.

-- 
Dag Sverre