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

Jason R Huggins JRHuggins at thoughtworks.COM
Mon Oct 9 18:52:37 CEST 2006


Chris McAvoy wrote on 10/05/2006 01:18:44 PM:
> On 10/5/06, Jason R Huggins wrote:
> > FYI... first response... "We rolled our own".   :-/
> >
> 
> After your first response a few days ago, roll your own has been on
> the top of my radar.  I sometimes forget that the languages we all
> like best really started out as "scripting" languages.  I sometimes
> forget that it's perfectly acceptable to write "scripts".


I was playing around with what a sample build script could/should look 
like in Python...

I stumbled into the following pseudo-code below. Which got me thinking... 
Why isn't it valid Python syntax? It should be! I was thinking, a "naked" 
token followed by a colon (e.g. "clean:") could be interpreted as a new 
module declaration... And because it's just a module, you can include 
functions and classes "embedded" into these module declarations. So 
looking at the code below... it would translate "build:" into a new 
module. If it was a real module on the filesystem, it would be a directory 
containing the classic "__init__.py" and its child modules "clean", 
"svn_checkout", "test", and "communicate". Looking at it, it reminds me 
alot of YAML.

So, is there any reason why in-line (aka 'embedded') module declarations 
would be a bad idea...  Or is this a PEP-able idea, you think?


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
 
-Jason


More information about the Chicago mailing list