[Chicago] Inline modules declarations? [tangent off of "Fw: using CruiseControl for non-java projects?"]

[Ian Bicking]

Jason R Huggins wrote:
> build:
>     clean:
>         os.system(<do some cleaning>)
>  
>     svn_checkout:
>         os.system(<do some code getting>)
>  
>     test:
>         # run unit tests
>  
>     communicate: 
>         send_email:
>             # notify the build mailing list
>  
>         update_rss: 
>             # update the rss feed

PEP 359 (http://www.python.org/dev/peps/pep-0359/) could allow this. 
Unfortunately its been withdrawn, though it still comes up over and 
over.  It would be nice if someone took it up again, as it still has 
fans (myself included, though I don't track py-dev enough to become its 
champion, at least not right now).

Anyway, with it you'd probably do:

make Build my_build:
     def clean():
         ...
     make Build communicate:
         def send_email(): ...


And so forth.  In this particular case "clean", "svn_checkout", etc. are 
really functions; Python code that is not executed until called.  You 
could even argue the whole thing is a class, but "make" and "class" are 
actually fairly similar mechanically.  Presumably "my_build communicate" 
is a second (or third?) level command, using a nested Build.

Anyway, the actual mechanics are pretty simple:

my_build = Build("my_build", (), {'clean': clean function, 
'communicate': Build('communicate', (), {'send_email': send_email 
function})})

It's for making declarative name-based structures easier to build; kind 
of like Lisp's S-Expressions, except where S-Exps are about nested 
tree-like structures, these are based more on dictionaries.  Anyway, you 
can totally do this with class statements, but it's kind of a pain in 
the butt and you have to explain to people why it looks like a class 
statement but isn't really.


-- 
Ian Bicking | ianb at colorstudy.com | http://blog.ianbicking.org