Skip to content

Idle does not check user config for extention configuration #89520

Closed

Description

@CoolCat467
mannequin
BPO 45357
Nosy @terryjreedy, @taleinat, @CoolCat467
PRs
  • gh-89520: IDLE - Make extentions use user's keys, not all defaults #28713
  • 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 = 'https://github.com/terryjreedy'
    closed_at = None
    created_at = <Date 2021-10-03.21:42:22.903>
    labels = ['expert-IDLE', 'type-feature', '3.11']
    title = 'Idle does not check user config for extention configuration'
    updated_at = <Date 2021-11-10.23:59:10.553>
    user = 'https://github.com/CoolCat467'

    bugs.python.org fields:

    activity = <Date 2021-11-10.23:59:10.553>
    actor = 'CoolCat467'
    assignee = 'terry.reedy'
    closed = False
    closed_date = None
    closer = None
    components = ['IDLE']
    creation = <Date 2021-10-03.21:42:22.903>
    creator = 'CoolCat467'
    dependencies = []
    files = []
    hgrepos = []
    issue_num = 45357
    keywords = ['patch']
    message_count = 5.0
    messages = ['403112', '403457', '403483', '403487', '406140']
    nosy_count = 3.0
    nosy_names = ['terry.reedy', 'taleinat', 'CoolCat467']
    pr_nums = ['28713']
    priority = 'normal'
    resolution = None
    stage = 'test needed'
    status = 'open'
    superseder = None
    type = 'enhancement'
    url = 'https://bugs.python.org/issue45357'
    versions = ['Python 3.11']

    Linked PRs

    Activity

    1. CoolCat467 commented on Oct 3, 2021

      CoolCat467mannequin
      MannequinAuthor

      I was trying to write an extension for Idle, and was noticing extension keys defined in ~/.idlerc weren't being used, so I looked into it and found that in idlelib.config.idleConf, GetExtensionKeys, __GetRawExtensionKeys, and GetKeyBinding would never check for user keys, always assuming default keys have everything. This is not always true. In a system with multiple users, you would not want to modify the default config file for a custom extension, as that is used for everyone.

    2. terryjreedy commented on Oct 8, 2021

      @terryjreedy
      Member

      I am puzzled by your report. As explained in the top of idlelib/confix-extensions.def, the options for four features are still defined there for compatibility reasons and user changes to those option *are* stored in ~/.idlerc/config-extensions.cfg and read on startup. At least on Windows with 3.9 and 3.11. I also tested changing options for test extension zzdummy and that works also. For instance, click enable, exit dialog, exit IDLE, reload, edit something, select Format, and the z options are listed. The default config is not changed. What tests did you run?

    3. CoolCat467 commented on Oct 8, 2021

      CoolCat467mannequin
      MannequinAuthor

      Yes, changing settings on ZzDummy works correctly, but this is because an entry for it exists in the default config file. The problem is when if you attempt to add a new extension through the user config file. When IDLE is looking for extensions to load, it only checks the default config file, not the user config file. So if I add a new extension entry to my ~/.idlerc/config-extensions.cfg file, "[lintcheck]\nenable = True", and have a module installed on my system called "lintcheck", with a class named "lintcheck". Because IDLE is only looking in the default config file for extensions to load, it never finds lintcheck and therefore it is never loaded. On the contrary, if it were in the system default config file, IDLE would find it and "lintcheck" would be loaded.

    4. terryjreedy commented on Oct 8, 2021

      @terryjreedy
      Member

      The current configuration design is that user .idlerc config-x.cfg files contain changes from the idlelib config-x.def files. A proposal to change this is an enhancement request rather than a bugfix request. It will make the logic more complex, increase maintenance burden, and likely make changes to the configuration system harder.

      If Python is installed for one user, any changes to config-extensions.def only apply to that one user, just as with additions to site-packages. If Python is installed for all users, why shouldn't extensions be available to all, just as with additions to site-packages? Assuming that extensions are by default not enabled, users will have to explicitly enable them, just as they have to explicitly import added packages.

      On a system with non-admin users, such as in a classroom, I can imagine that the admin user(s) might not want non-admin users to be able to modify IDLE behavior. I am reluctant to open this can of worms and would not do so by myself.

    5. added
      3.11only security fixes
      and removed
      type-bugAn unexpected behavior, bug, or error
      on Oct 8, 2021
    6. 18 remaining items

    7. added 4 commits that reference this issue on Apr 12, 2026
    8. gpshead commented on Apr 12, 2026

      @gpshead
      Member

      cleaned up and merged, thanks!

    9. moved this from In Progress to Done in IDLE Issueson Apr 12, 2026
    10. added a commit that references this issue on Apr 25, 2026
    11. added 2 commits that reference this issue on Jul 4, 2026
    12. added a commit that references this issue on Aug 11, 2026
    Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

    Metadata

    Metadata

    Assignees

    Labels

    Projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions