On Mon, Jan 24, 2011 at 11:33 PM, Stefan Behnel <stefan...@behnel.de> wrote: > Vitja Makarov, 25.01.2011 08:15: >> I want to write simple code to find unbound variables.
I'm assuming you mean unassigned (as opposed to unbound in, e.g., a closure)? > There is some code that does (part of) that already, in a transform IIRC. > It's used to detect if we need to initialise a local variable to None or > can safely set it to NULL. > > >> As it's hard to detect them in common case it will mark them as: >> - bound (defenitley bound) >> def foo(): >> a = 1 >> print a >> >> Bound variables should be initialized to NULL >> >> - unbound (defenitley unbound) >> def foo(): >> print a >> a = 1 >> >> Unbound variables should be initialized to Py_None. >> And user may be warned (should depend on command line flags) >> >> - don't know (not sure here) >> def foo(x): >> if x: >> a = 1 >> [else: # optional >> a = 2] >> print a >> >> Algo is too stupid it don't know much about branches, so it's not sure here. > > Well, it *can't* know what will happen at runtime. That's not being stupid > at all, it's just the correct way to do it. If the else clause is there, it should be smart enough. Loops are a bit trickier. >> This ones will be initialized to Py_None. > > To be correct, they'd have to get initialised to NULL and a check needs to > get generated on read access as long as we don't know for sure if it has > been initialised or not. CPython raises an exception on unbound locals, so > Cython should do the same and should do it efficiently. When we get to the > point that we safely know which variables are being initialised and for > which only the runtime behaviour can tell us if they are or not, I think > it's fine to add the little performance penalty of checking for NULL in > exactly the unsafe cases. Note also that assignment, and possibly cleanup, needs to be made NULL-safe as well. >> Also I would like to check for unused variables We already do this (to avoid compiler warnings). >> and unreachable code >> (this should be removed). > > Some unreachable code is getting dropped during constant folding, usually > stuff like "if False: ...", but I agree that there's always more that can > be done. Think of this: > > def x(): > do_some_stuff() > > return # disable rest of code, e.g. during debugging > > unreachable_code() > > Cython shouldn't bother generating dead code here (even if the C compiler > would drop it anyway). Personally, I think it's better to focus on stuff that the C compiler can't do for us, but if it doesn't complicate things too much than it's nice to have. > Knowing where a function returns and if it has trailing code with a default > None return would also be good to know. It would be a step towards > inferring the return type of functions automatically. Yep, that would be nice. Currently we don't have much (anything?) in the way of control flow analysis. It probably wouldn't be too hard to walk the tree to discover this kind of information, recording on each NameNode as one goes along what its possible states are. - Robert _______________________________________________ Cython-dev mailing list Cython-dev@codespeak.net http://codespeak.net/mailman/listinfo/cython-dev
