8000 configparser can't parse MySQL style config · Issue #65528 · python/cpython · GitHub
[go: up one dir, main page]

Skip to content

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

Open
dveeden mannequin opened this issue Apr 22, 2014 · 4 comments
Open

configparser can't parse MySQL style config #65528

dveeden mannequin opened this issue Apr 22, 2014 · 4 comments
Labels
stdlib Python modules in the Lib dir type-feature A feature request or enhancement

Comments

@dveeden
Copy link
Mannequin
dveeden mannequin commented Apr 22, 2014
BPO 21329
Nosy @bitdancer, @ambv, @vadmium
Files
  • demo.py: Quick-n-dirty example
  • 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:

    assignee = None
    closed_at = None
    created_at = <Date 2014-04-22.15:27:33.250>
    labels = ['type-feature', 'library']
    title = "configparser can't parse MySQL style config"
    updated_at = <Date 2014-09-28.02:12:09.576>
    user = 'https://bugs.python.org/dveeden'

    bugs.python.org fields:

    activity = <Date 2014-09-28.02:12:09.576>
    actor = 'martin.panter'
    assignee = 'none'
    closed = False
    closed_date = None
    closer = None
    components = ['Library (Lib)']
    creation = <Date 2014-04-22.15:27:33.250>
    creator = 'dveeden'
    dependencies = []
    files = ['35001']
    hgrepos = []
    issue_num = 21329
    keywords = []
    message_count = 3.0
    messages = ['217012', '218473', '227748']
    nosy_count = 4.0
    nosy_names = ['r.david.murray', 'lukasz.langa', 'martin.panter', 'dveeden']
    pr_nums = []
    priority = 'normal'
    resolution = None
    stage = None
    status = 'open'
    superseder = None
    type = 'enhancement'
    url = 'https://bugs.python.org/issue21329'
    versions = ['Python 3.5']

    @dveeden
    Copy link
    Mannequin Author
    dveeden mannequin commented Apr 22, 2014

    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:
    [mysqld]
    log_bin
    innodb_file_per_table
    innodb_io_capacity=800

    However it can't parse this config:
    [mysqld]
    log_bin
    innodb_file_per_table
    innodb_io_capacity=800
    replicate-do-db="test1"
    replicate-do-db="test2"

    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
    "To specify more than one database, use this option multiple times, once for each database"

    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:
    https://docs.python.org/3/library/configparser.html#customizing-parser-behaviour

    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.

    @dveeden dveeden mannequin added the stdlib Python modules in the Lib dir label Apr 22, 2014
    @bitdancer
    Copy link
    Member

    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 :)

    @bitdancer bitdancer added the type-feature A feature request or enhancement label May 13, 2014
    @vadmium
    Copy link
    Member
    vadmium commented Sep 28, 2014

    See bpo-12662 for a related earlier proposal. (Although the multimap proposal here sounds better than concatenating the values as proposed there.)

    @serhiy-storchaka
    Copy link
    Member

    See also #75709 and #107430.

    Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
    Labels
    stdlib Python modules in the Lib dir type-feature A feature request or enhancement
    Projects
    None yet
    Development

    No branches or pull requests

    3 participants
    0