Skip to content
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

IDLE: add docstrings to #74859

csabella opened this issue Jun 15, 2017 · 8 comments

IDLE: add docstrings to #74859

csabella opened this issue Jun 15, 2017 · 8 comments
3.7 (EOL) end of life topic-IDLE type-feature A feature request or enhancement


Copy link

BPO 30674
Nosy @terryjreedy, @mlouielu, @csabella
  • bpo-30674: IDLE: add docstrings to #2213
  • [3.6] bpo-30674: IDLE: add docstrings to (GH-2213) #2434
  • 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 = ''
    closed_at = <Date 2017-06-27.07:03:19.537>
    created_at = <Date 2017-06-15.12:27:17.378>
    labels = ['expert-IDLE', 'type-feature', '3.7']
    title = 'IDLE: add docstrings to'
    updated_at = <Date 2017-06-27.07:03:19.537>
    user = '' fields:

    activity = <Date 2017-06-27.07:03:19.537>
    actor = 'terry.reedy'
    assignee = 'terry.reedy'
    closed = True
    closed_date = <Date 2017-06-27.07:03:19.537>
    closer = 'terry.reedy'
    components = ['IDLE']
    creation = <Date 2017-06-15.12:27:17.378>
    creator = 'cheryl.sabella'
    dependencies = []
    files = []
    hgrepos = []
    issue_num = 30674
    keywords = []
    message_count = 8.0
    messages = ['296199', '296200', '296206', '296211', '296217', '296220', '297013', '297017']
    nosy_count = 3.0
    nosy_names = ['terry.reedy', 'louielu', 'cheryl.sabella']
    pr_nums = ['2213', '2434']
    priority = 'normal'
    resolution = 'fixed'
    stage = 'resolved'
    status = 'closed'
    superseder = None
    type = 'enhancement'
    url = ''
    versions = ['Python 3.6', 'Python 3.7']

    @csabella csabella added the 3.7 (EOL) end of life label Jun 15, 2017
    @csabella csabella added topic-IDLE type-feature A feature request or enhancement labels Jun 15, 2017
    Copy link

    On PR 2213, Cheryl said "One other question -- when I run this, the dialog box always opens way on the bottom of my screen. Has anyone requested a change to this before? Or would it be worth mentioning on idle-dev?" Louie sees top left on Mac, I see same on Windows.

    Same is true for me for all search boxes. Cheryl, only grep box or others? I would find bottom surprising and likely annoying. Feel free to open issue with detail. Louie, what do you see on Linux?

    Copy link

    mlouielu mannequin commented Jun 16, 2017

    On Linux, it stick to the top-right of the IDLE, that says I can't reproduce the bump-out at the bottom :(

    Copy link

    Are you two using different Linux distributions with different graphics managers? Could tk act different on different distributions?

    Copy link
    Contributor Author

    Thanks. It seems like my windows pop-up all over the place. It's probably a Ubuntu thing.

    I was used to looking at help_about and textview, which cascade over the current window (I think because of self.geometry) and that's what prompted my initial question. But, the search dialogs aren't even all the same.

    If IDLE is in the middle of the screen,

    • 'Find' and 'replace' pin to the top left of my screen, as far top and as far left as it could go.
    • 'Find in files' pins to the bottom left, as far to the bottom as possible.

    If I move the IDLE window, it generally stays the same as above, but if IDLE is in the top left, then the find and replace are to the right of it and find in files is still at the bottom.

    I was going to ask this anyway, but help_about and those dialogs inherit from Toplevel and have a parent, but searchbase doesn't. I don't understand why there's a difference. The search dialogs are modal, even though the Output Window isn't. Maybe it would help to control where they display in relation to a parent window?

    Copy link

    Since all three search boxes call the same open, they use the same hidden placement algorithm. On Windows, the last position when closed is re-used for the next open for the duration of the IDLE session. When IDLE is closed and reopened, the initial position is reset to a 'cascade' position. What about Ubuntu? Is it remembering across IDLE sessions?

    The 'difference' you noticed concerns 'is-a' relationships (via inheritance) versus 'has-a' relationships (via composition). It is a perennial debate among some in the OOP community, with no resolution. Python allows both.

    IDLE uses both. Different people? Same person, different times? Some perceived specific reason for each? I slightly prefer 'is-a' because it seems simpler, and inheritance does not bother me. When we 'framify' the search widgets, I expect to use Frame subclasses.

    Perhaps more important is grab-bag or kitchen-sink classes versus focused classes. EditorWindow has a TopLevel, a Frame placed within the Toplevel, and, among other things, a Multicall-wrapped Text placed within the frame. A method can be about any of them, and there are methods not about any of them, or about editing (open turtledemo). There should be separate window, frame, and text classes with the methods appropriate to each. I am sure that this would make the editor easier to learn, test and patch.

    Modal or not is a separate debate. Most recent opinions have been to make fewer things modal. bpo-24813 would make About IDLE non-modal. bpo-24039 and bpo-24760 include search dialogs.

    Copy link
    Contributor Author

    Thanks, Terry. It seems that it *is* the hidden placement algorithm and I just never noticed it before. I opened a bunch of terminal windows and they opened top left, bottom left, top right, bottom right, then continuing to follow a pattern. IDLE did the same thing. However, it isn't always opening the search dialogs in the same place even when I open the three in a row. Maybe it's the size of the windows or something else that is causing the algorithm to render them differently. Even though I can now understand the behavior, it's still frustrating because I'd expect the search box to pop up where I'm looking and not somewhere else on the screen entirely.

    I have Windows 7 on my work laptop with 2 monitors and behavior was better. The search dialogs opened more in the middle of the screen, near the IDLE window. Although, if I put IDLE on the left monitor, the search dialog still opened in the same place on the right monitor, but it was easy to notice.

    Thanks for explaining all that about the windows and dialogs. At this point, I would say that consitency within the app would make it easier to understand for me as a newcomer. If everything followed the pattern of window, frame, and text, then I wouldn't wonder about the differences, especially if there really isn't any intended difference. And thank you for the links to those other issues and discussions.

    Copy link

    New changeset 65474b9 by terryjreedy (csabella) in branch 'master':
    bpo-30674: IDLE: add docstrings to (bpo-2213)

    Copy link

    New changeset 39e501a by terryjreedy in branch '3.6':
    [3.6] bpo-30674: IDLE: add docstrings to (GH-2213) (bpo-2434)

    @ezio-melotti ezio-melotti transferred this issue from another repository Apr 10, 2022
    Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
    3.7 (EOL) end of life topic-IDLE type-feature A feature request or enhancement
    None yet

    No branches or pull requests

    2 participants