-
-
Notifications
You must be signed in to change notification settings - Fork 32.2k
configparser can't parse MySQL style config #65528
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Comments
With Python 2.7 the ConfigParser was enriched with the allow_no_value option which resulted in a much more usable configparser for MySQL configs. It can now parse configs like this: However it can't parse this config: A comma separated config might have been better, but that's not the case with many MySQL config (and probably doesn't even work for this option). From http://dev.mysql.com/doc/refman/5.6/en/replication-options-slave.html#option_mysqld_replicate-do-db The dict/orderedDict which is used by configparser doesn't easlily allow to store a config like this. The MySQL config file is used as an example in the documentation: This could be solved by having a list of values if the key exists more than once. Python 3 improves this a bit by giving a DuplicateOptionError by default. |
The data structure you are asking for bears a resemblance to the data structure used by the email package to record message headers. Email uses a list with a dict-like API cobbled together on top. The difference with your suggestion is that email also needs to record the order of the headers, so just having a list-of-values for each key isn't adequate. Any bets on whether or not we eventually run across a use of .ini format where the exact order of the duplicated keys within the whole list of keys matters? :) With two use cases that could be served by the same data structure in the stdlib, I wonder if it is worth actually building the abstract data type. Probably not, but I thought I'd raise the possibility anyway :) |
See bpo-12662 for a related earlier proposal. (Although the multimap proposal here sounds better than concatenating the values as proposed there.) |
Note: these values reflect the state of the issue at the time it was migrated and might not reflect the current state.
Show more details
GitHub fields:
bugs.python.org fields:
The text was updated successfully, but these errors were encountered: