> I just mean that there should be a > clear and easy way to do it, that it should be considered a basic > service, and that if the best way to satisfy all the goals is to > integrate it directly into the language, that shouldn't be shied away > from.
Honestly, the programming language and the configuration languages should never, ever, ever be inseparable. I don't see a reason for it and I see some great reasons not to do it. > The example that I have on my blog post, I consider that 'syntax', > even though it's implemented as a function, mainly just because it > digs into the bytecode and modifies the normal way a function is > evaluated (the function's value is determined by where the output > would go). I don't particularly see why this is needed. To my mind the strongest argument you are making, by far, is the "discoverable" argument. If you were able to build a system which permitted other components to discover configuration options and give configurable levels of permanence and visibility to them, that would be great. If you were able to do it and make it easy for a programmer to interact with, you would most definitely have a module I would use. But I daresay you're going to have to build it (or at least mock it up) before you're going to get a lot of folks jumping on the bandwagon, and its a *long* slog before you hit the level of support and stability you're going to need to convince folks to trust their precious config files to it. -- http://mail.python.org/mailman/listinfo/python-list
