[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