Skip to main content
added 578 characters in body
Source Link
Celada
  • 664
  • 4
  • 6

+1 to everything in amon's answer. I'd like to add this:

You'll regret using Python code as your configuration language the first time you want to import the same configuration from within code written in a different language. For example if code that's part of your project and it written in C++ or Ruby or something else needs to pull in the configuration, you'll need to link in the Python interpreter as a library or parse the configuration in a Python coprocess, both of which are awkward, difficult, or high-overhead.

All of the code that imports this configuration today may be written in Python, and you may think this will be true tomorrow as well, but do you know for sure?

You said you would use logic (anything other that static data structures) in your configuration sparingly if at all, which is good, but if there's any bit of that at all, you'll find it difficult in the future to undo it so you can move back to a declarative configuration file.

EDIT for the record: several people have commented on this answer about how likely or unlikely it is that a project would ever be successfully completely rewritten in another language. It's fair to say that a complete backward-compatible rewrite is probably rarely seen. What I actually had in mind was bits and pieces of the same project (and needing access to the same configuration) being written in different languages. For example, serving stack in C++ for speed, batch database cleanup in Python, some shell scripts as glue. So spend a thought for that case too :)

+1 to everything in amon's answer. I'd like to add this:

You'll regret using Python code as your configuration language the first time you want to import the same configuration from within code written in a different language. For example if code that's part of your project and it written in C++ or Ruby or something else needs to pull in the configuration, you'll need to link in the Python interpreter as a library or parse the configuration in a Python coprocess, both of which are awkward, difficult, or high-overhead.

All of the code that imports this configuration today may be written in Python, and you may think this will be true tomorrow as well, but do you know for sure?

You said you would use logic (anything other that static data structures) in your configuration sparingly if at all, which is good, but if there's any bit of that at all, you'll find it difficult in the future to undo it so you can move back to a declarative configuration file.

+1 to everything in amon's answer. I'd like to add this:

You'll regret using Python code as your configuration language the first time you want to import the same configuration from within code written in a different language. For example if code that's part of your project and it written in C++ or Ruby or something else needs to pull in the configuration, you'll need to link in the Python interpreter as a library or parse the configuration in a Python coprocess, both of which are awkward, difficult, or high-overhead.

All of the code that imports this configuration today may be written in Python, and you may think this will be true tomorrow as well, but do you know for sure?

You said you would use logic (anything other that static data structures) in your configuration sparingly if at all, which is good, but if there's any bit of that at all, you'll find it difficult in the future to undo it so you can move back to a declarative configuration file.

EDIT for the record: several people have commented on this answer about how likely or unlikely it is that a project would ever be successfully completely rewritten in another language. It's fair to say that a complete backward-compatible rewrite is probably rarely seen. What I actually had in mind was bits and pieces of the same project (and needing access to the same configuration) being written in different languages. For example, serving stack in C++ for speed, batch database cleanup in Python, some shell scripts as glue. So spend a thought for that case too :)

clarify following comments.
Source Link
Celada
  • 664
  • 4
  • 6

+1 to everything in amon's answer. I'd like to add this:

You'll regret using Python code as your configuration language the first time you want to import the same configuration from within code written in a different language. For example if code that's part of your project and it written in C++ or Ruby or something else needs to pull in the configuration, you'll need to link in the Python interpreter as a library or parse the configuration in a Python coprocess, both of which are awkward, difficult, or high-overhead.

All of the code that imports this configuration today may be written in Python, and you may think this will be true tomorrow as well, but do you know for sure?

You said you would use logic (anything other that static data structures) in your configuration sparingly if at all, which is good, but if there's any bit of that at all, you'll find it difficult in the future to undo it so you can move back to a declarative configuration file.

+1 to everything in amon's answer. I'd like to add this:

You'll regret using Python code as your configuration language the first time you want to import the same configuration from within code written in a different language. All of the code that imports this configuration today may be written in Python, and you may think this will be true tomorrow as well, but do you know for sure?

You said you would use logic (anything other that static data structures) in your configuration sparingly if at all, which is good, but if there's any bit of that at all, you'll find it difficult in the future to undo it so you can move back to a declarative configuration file.

+1 to everything in amon's answer. I'd like to add this:

You'll regret using Python code as your configuration language the first time you want to import the same configuration from within code written in a different language. For example if code that's part of your project and it written in C++ or Ruby or something else needs to pull in the configuration, you'll need to link in the Python interpreter as a library or parse the configuration in a Python coprocess, both of which are awkward, difficult, or high-overhead.

All of the code that imports this configuration today may be written in Python, and you may think this will be true tomorrow as well, but do you know for sure?

You said you would use logic (anything other that static data structures) in your configuration sparingly if at all, which is good, but if there's any bit of that at all, you'll find it difficult in the future to undo it so you can move back to a declarative configuration file.

Source Link
Celada
  • 664
  • 4
  • 6

+1 to everything in amon's answer. I'd like to add this:

You'll regret using Python code as your configuration language the first time you want to import the same configuration from within code written in a different language. All of the code that imports this configuration today may be written in Python, and you may think this will be true tomorrow as well, but do you know for sure?

You said you would use logic (anything other that static data structures) in your configuration sparingly if at all, which is good, but if there's any bit of that at all, you'll find it difficult in the future to undo it so you can move back to a declarative configuration file.