Timeline for How bad of an idea is it to use Python files as configuration files?
Current License: CC BY-SA 3.0
17 events
when toggle format | what | by | license | comment | |
---|---|---|---|---|---|
Jun 21, 2017 at 22:17 | comment | added | Celada | @nneonneo, sure. There are always workarounds. It's still technical debt. | |
Jun 20, 2017 at 1:28 | comment | added | nneonneo | If bits are written in other languages, couldn't you define a internal protocol to communicate configuration to those other bits? In all likelihood you'd retain Python (or whatever) as the high-level glue that binds the rest together, in which case one of its responsibilities would be to parse the config and pass that on to other components. | |
Jun 19, 2017 at 20:12 | history | edited | Celada | CC BY-SA 3.0 |
added 578 characters in body
|
Jun 19, 2017 at 15:55 | comment | added | Kevin Fee | I had to do this a few years ago when a tool written in Lua used Lua script as its configs, then they wanted us to write a new tool in C#, and specifically asked us to use the Lua config script. They had a total of 2 lines that were actually programmable and not simple x = y, but I still had to learn about open source Lua interpreters for .net because of them. It's not a purely theoretical argument. | |
Jun 19, 2017 at 13:17 | comment | added | Dmitry Grigoryev | This is exactly the argument people had against XML 10 years ago. | |
Jun 19, 2017 at 13:09 | comment | added | Voo | @JonBentley I have yet to see any real world project that kept backwards compatibility when it was completely rewritten in another language. Hell I can't think of any successful project that was completely rewritten to begin with (I thought we learned that lesson from Netscape, or Borland.. ok maybe we don't learn that lesson very well). This strikes me as a pretty theoretical worry. And if backcomp isn't a problem (as it would if you were say porting to Android), the fact that you have to port your whole project dwarfs any cost of having to rethink and rewrite your config file system anyhow. | |
Jun 18, 2017 at 23:39 | comment | added | code_dredd | @JonBentley I think those are good points, but libraries often imply additional/external dependencies that may be undesirable or unavailable (e.g. sysadmin too worried that installing a module will require updates to others and might "break production"). Some languages may be more susceptible to this (e.g. Perl) than others. | |
Jun 18, 2017 at 23:33 | comment | added | Jon Bentley | @ray True, but the answer is still useful on the basis that questions shouldn't just be applicable to the person who posts them. If you use a standardized format (e.g. INI, JSON, YAML, XML, etc.) then you will likely be using an existing parsing library rather than writing your own. That reduces the additional work to just an adapter class to interface with the parsing library. If you are limiting yourself to key=value, then that does away with most of the OP's reasons to use Python in the first place and you might as well just go with a recognized format. | |
Jun 18, 2017 at 22:38 | comment | added | Izkata |
@ray That said, if you're going to restrict yourself to key=value for that purpose, python already has configparser, and java has ini4j, etc etc. Or just go json as OP suggested in the first place.
|
|
Jun 18, 2017 at 19:54 | comment | added | code_dredd |
@JonBentley I suppose the concern will be relevant if there're plans to do multi-language projects. I didn't get that impression from the OP. Additionally, using text files for config still requires additional code (in all languages) for actual parsing/conversion of values. Technically, if they limit the Python side to key=value assignments for config, I don't see why a Java/C++ program couldn't read the Python file as a plain text file and parse it the same if they need to move to something else in the future. I don't see a need for a full-fledged Python interpreter.
|
|
Jun 18, 2017 at 19:37 | comment | added | Jon Bentley | @Mast I think you're parsing it wrong. The point I took from this answer (both original and edited) is that the choice to write configuration files in a programming language is that it makes it harder to write code in another language. E.g. you decide to port your app to Anrdoid / iPhone and will be using another language. You either have to (a) rely on a Python interpreter on the mobile phone app (not ideal), (b) re-write the configuration in a language-independent format and rewrite the Python code that used it, or (c) maintain two configuration formats going forward. | |
Jun 18, 2017 at 19:14 | history | edited | Celada | CC BY-SA 3.0 |
clarify following comments.
|
Jun 18, 2017 at 19:11 | comment | added | Celada | All right, let me try to clarify by editing I guess... | |
Jun 18, 2017 at 19:08 | comment | added | Mast | Either that wasn't clear from your answer or I'm simply parsing it wrong. In any case, why does it matter he needs a Python interpreter? OP indicates he's in a Python environment now, so it's available. It just so happens to be available by default on GNU/Linux systems because it's used for the configuration of the OS. So I'm not surprised OP wants to do something similar for his applications. | |
Jun 18, 2017 at 19:01 | comment | added | Celada | @Mast, apologies, but I don't follow. The name of the file (whether or not it ends in .py) is neither here nor there. The point I am trying to make is that if it's written in Python then you need a Python interpreter to read it. | |
Jun 18, 2017 at 18:58 | comment | added | Mast | One of the rules of Python programs is they should carry the .py extension. So, yea, you will know it's written in Python. Of-course, the file can simply contain JSON and still work as intended, but that's beside the point here I think. | |
Jun 18, 2017 at 18:55 | history | answered | Celada | CC BY-SA 3.0 |