You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The current interpolation syntax is very flexible but probably unnecessarily complicated: the characters allowed in section and option names are already very limited by default, so only the interpolation start character could be introduced by a special character. Also, the configured section separator could be used to separate the sections in the path and the option name too. For example:
I always thought it was funny that options in a Section object are accessed using the square brackets syntax, but sections in a ConfigFile objects are accessed using round brackets, even though they are denoted as [name] in the config file itself. And on top of that interpolation introduces braces...
To avoid the : problem in the last example, the specification could be something like
$[section1.section2]${option}
where the ${} group is optionally preceded by the $[] group. The type of the brackets could be adjusted with regard to the note above.
Sections must be accessed with round brackets because that's Python's (and not only its) syntax for function calls. In config files, though, it's more standard to use square brackets, but you can monkey-patch the setting with the latest commits in the develop branch, and #5 will give a cleaner way to do it.
About your alternative, it's of course another valid idea, maybe I'll end up making interpolation an integer value allowing to choose between various styles ;)
The current interpolation syntax is very flexible but probably unnecessarily complicated: the characters allowed in section and option names are already very limited by default, so only the interpolation start character could be introduced by a special character. Also, the configured section separator could be used to separate the sections in the path and the option name too. For example:
In this case a leading
.
should mean a relative path.In this case a leading
/
should mean an absolute path.Note that this change would create a backward incompatibility!
Edit: if using something like:
The option name shouldn't need to forbid the section separator, although section names should also forbid the
:
.The text was updated successfully, but these errors were encountered: