On Apr 1, 8:56 pm, CTO <debat...@gmail.com> wrote: > > 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.
I'm not saying the actual end-user configuration language would be tied to the programming language. I'm starting to think a better way to describe this is to play down configuration as a use case, and instead focus on what the actual mechanism is: a way to define points in your program that can have values injected into them at runtime by some external entity, a uniform naming scheme for those points derived from the code, and a way to expose those points to interested consumers. > > 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. It was a stab at the 'uniform naming scheme' - the function fetches a config value based on a key derived from the name of the variable its output will be assigned to. It definitely needs more thought, but at least I got to play around with the bytecode tools :) > 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. Agreed, and I do intend to do a proper mockup when I get the time; I just wanted to get some initial reactions. Thanks for your feedback. -- http://mail.python.org/mailman/listinfo/python-list
