On Monday, October 1, 2012 10:42:02 PM UTC+8, Chris Angelico wrote: > On Tue, Oct 2, 2012 at 12:37 AM, Jason Friedman <ja...@powerpull.net> wrote: > > >> Is there a reason to use that format, rather than using Python > > >> notation? I've at times made config files that simply get imported. > > >> Instead of a dictionary, you'd have a module object: > > >> > > >> > > >> # config.py > > >> VAR1='foo' > > >> VAR2='bar' > > >> VAR3=VAR1+VAR2 > > >> > > > There is a reason: /path/to/export_file exists for Bash scripts, too, > > > and I do not think I could get Bash to read config.py in the format > > > stated above. I want to maintain only one file. > > > > (Responding on-list and hoping it was merely oversight that had that > > email come to me personally) > > > > Ah, fair enough. Well, since you're using the full range of bash > > functionality, the only viable way to parse it is with bash itself. > > I'd recommend going with the version you have above: > > > > > * * * * * . /path/to/export_file && /path/to/script.py > > > > Under what circumstances is this not an option? That'd be the next > > thing to consider. > > > > Alternatively, you may want to consider making your own config file > > format. If you consciously restrict yourself to a severe subset of > > bash functionality, you could easily parse it in Python - for > > instance, always look for "export %s=%s" with simple strings for the > > variable name and value. > > > > ChrisA
I think one can ues some decorators to wrap OS or platform dependent functions. I am sure someone did that long time ago as the iron python wrapped dot-net. -- http://mail.python.org/mailman/listinfo/python-list
