On 14 September 2011 08:26, Corbin Simpson <<a href="mailto:mostawesomedude@gmail.com">mostawesomedude@gmail.com</a>> wrote: <div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;"> Hi, I've talked about it a bit before, but I feel that it's getting out of hand, so it's time to talk about cleaning up some of the Python that's used to generate/build Mesa. First, the biggest problem is that our Python's completely untested and unstructured. It's very ad-hoc. This might be alright for some of the codegen, but the rather extensive total weight of all of these scripts is over 20 KLOCs, and this is just too much code to be scattered about with very little organization. There are zero Python packages (folders with __init__.py) in Mesa. Here are a handful of problems exposed by pyflakes, a minimal static analysis tool which only catches syntax errors, unused names, and undefined names. This is really only tip-of-the-iceberg stuff, but I don't feel comfortable sending patches for this stuff without talking to the people that wrote this code originally. * /src/gallium/drivers/llvmpipe/lp_tile_shuffle_mask.py has a syntax error in global scope; it can't possibly run. * /scons/wcesdk.py has an undefined name in what appears to be dead code. This probably isn't a problem because I don't think any of us care about WinCE. (Which leads to the question: Why is this in the tree?) * /src/mapi/glapi/gen/*.py have undefined calls to show_usage(), which I anticipate should show a usage message and exit. However, since these are generally only called from Makefiles, they shouldn't be a problem. Of course, people might have trouble running them manually... * /src/mapi/mapi/mapi_abi.py has a couple more undefined names in error paths. What are people's opinions on this? Is it worth spending some time to clean up some of this code? </blockquote><div> I'm generally in favor of clean-up, especially when it (a) fixes rarely-encountered bugs, (b) improves clarity, or (c) increases the number of people who understand a given piece of code. I'm not sure we'll get too much of (a) in this case (since most of the code is only used at compile time and always acts on the same input, every bug is either common or benign), but we can probably get a lot of benefit in the (b) and (c) departments. Also, Python 3 is slowly taking hold (it's already the standard Python in archlinux, and I expect others to follow), so some time in the next year or so we might want to upgrade our Python scripts to use Python 3. It would be nice to do a round of clean-up before we attempt that. I've done professional Python development in the past, so I will try to help with code review. Paul </div></div>