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: conceptual problems with *Class browser* #60437

Closed
fgracia mannequin opened this issue Oct 14, 2012 · 9 comments
Closed

IDLE: conceptual problems with *Class browser* #60437

fgracia mannequin opened this issue Oct 14, 2012 · 9 comments
Labels
topic-IDLE type-bug An unexpected behavior, bug, or error

Comments

@fgracia
Copy link
Mannequin

fgracia mannequin commented Oct 14, 2012

BPO 16233
Nosy @terryjreedy, @serwy
Files
  • message_fix.patch
  • 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 = <Date 2014-10-16.02:05:02.492>
    created_at = <Date 2012-10-14.15:52:29.142>
    labels = ['expert-IDLE', 'type-bug']
    title = 'IDLE: conceptual problems with *Class browser*'
    updated_at = <Date 2014-10-16.02:05:02.490>
    user = 'https://bugs.python.org/fgracia'

    bugs.python.org fields:

    activity = <Date 2014-10-16.02:05:02.490>
    actor = 'terry.reedy'
    assignee = 'none'
    closed = True
    closed_date = <Date 2014-10-16.02:05:02.492>
    closer = 'terry.reedy'
    components = ['IDLE']
    creation = <Date 2012-10-14.15:52:29.142>
    creator = 'fgracia'
    dependencies = []
    files = ['27666']
    hgrepos = []
    issue_num = 16233
    keywords = ['patch']
    message_count = 9.0
    messages = ['172891', '173577', '173578', '182593', '182611', '229504', '229506', '229508', '229509']
    nosy_count = 5.0
    nosy_names = ['terry.reedy', 'roger.serwy', 'python-dev', 'Ramchandra Apte', 'fgracia']
    pr_nums = []
    priority = 'normal'
    resolution = 'fixed'
    stage = 'resolved'
    status = 'closed'
    superseder = None
    type = 'behavior'
    url = 'https://bugs.python.org/issue16233'
    versions = ['Python 2.7', 'Python 3.4', 'Python 3.5']

    @fgracia
    Copy link
    Mannequin Author

    fgracia mannequin commented Oct 14, 2012

    The *File* option in the menu bar of both the Python shell and the program editor have an entry called *Class Browser*.

    If one selects it from the shell window, one gets always an error message with the title: "No filename" which says: "This buffer has no associated filename". This happens whatever the previous history of the current interactive session.

    If one selects it from the editor window with a Python module loaded, then another window shows correctly the expected information about the classes defined in such a module, if any. The same previous error
    appears if the current contents of the editor are not recognised as a Python module (for instance by not having been yet saved), which is reasonable.

    IDLE's help says:
    "Class Browser -- Show classes and methods in current file".

    This does not clarify things much (what does *current file* mean from the shell window?) and does not permit one to get a coherent idea of the purpose originally intended for the option (a module imported in
    the current interactive session could not be rightly understood as a *current file*?).

    I find this situation quite confuse and would suggest that some action could be taken in order to at least clarify it, if not improve it, as for instance (in order of desirability and --very likely-- difficulty):

    - Just make the error message less puzzling and more informative when coming from the shell window (what does \*buffer* mean in this context?) and let the help file explain that this operation has only sense in connection with Python scripts being edited (if that is 
    

    the case, as it seems).
    - Disable the option in the shell window.
    - Suppress the option in the shell window and keep it only in the editor window when the document it is handling is recognised as a Python module.
    - Keep the option also in the shell window and make it display information about the classes defined in the namespace of the current interactive session, if any. I think that this is what would be a real and useful *class browser*.

    Thank you in advance for your attention.

    @fgracia fgracia mannequin added type-feature A feature request or enhancement topic-IDLE labels Oct 14, 2012
    @serwy
    Copy link
    Mannequin

    serwy mannequin commented Oct 23, 2012

    Saving the shell to a file allows the class browser to function. However a class browser for a syntax-incorrect file due to prompts and stdout contents can also pose a conceptual problem.

    I suggest that the error message be modified to include a corrective action: "This buffer has no associated filename. Please save this buffer to a file and try again."

    @serwy
    Copy link
    Mannequin

    serwy mannequin commented Oct 23, 2012

    Attached is a quick patch to change the error message.

    @RamchandraApte
    Copy link
    Mannequin

    RamchandraApte mannequin commented Feb 21, 2013

    IMO, Class Browser shouldn't even appear in PyShell.

    @terryjreedy
    Copy link
    Member

    Conceptual problems indeed. I never tried the 'class browser' because I mostly write modules with functions, not classes. Nonetheless, to see what this issue is about, I just tried it with one of my function-only files, expecting to see an empty 'show', whatever that would be. Instead I see new window with a nice listing of all the function definitions in the file.

    & xxx.py
    |- & def a(...)
    |- & def b(...)
    (& is a green Python snake)

    But why must the file be open? Left click, right click, left double click, and the answer appears. The cursor in the open edit window moves to the corresponding def line, which is highlighted. So this is not just a class browser, but a module file navigator. This is a real gem that I should have been using, and would have if it were properly labeled and documented. I think the help/manual entry should be something like

    Module Browser -- Summarize the function, class, and method statements in a opened module file with a tree structure in an auxiliary window. Double clicking on any line in the tree activates the corresponding edit window, moves its cursor to the beginning of the corresponding def or class statement, and highlights the first line of that statement.

    (I did check that lambda expressions are ignored.)

    Since this feature can almost never be useful in PyShell, I agree that 'Module Browser' (or whatever new name we choose) should best not be present, or grayed out, or always fail with a shell specific message. But it seems that while shell and edit windows each have some main menu entries that the other does not, the submenus present in each are the same, so this might not be trivial (or the context specific message might be the easiest change).

    I think we can further improve the error message. I think 'this edit window' would be clearer that 'this buffer'. I think it should also specify that it only works with python module file. If someone who is editing a new non-Python file follows the instruction to save and try again, they will only be frustrated.

    I have two complaints about the browser window itself. The first is that the line spacing is not adjusted for my larger than default font (which I need for my less than 'default' vision). Consequently, each line cuts off the bottoem of the chars in the line above. This is a bug.

    The other is that the green snake at the beginning of *every* line is just distracting visual noise. The one before xxx.py is enough.

    I think all the mentioned changes can go in all current versions.

    @terryjreedy terryjreedy added type-bug An unexpected behavior, bug, or error and removed type-feature A feature request or enhancement labels Feb 21, 2013
    @terryjreedy
    Copy link
    Member

    I opened bpo-22628 for the TreeWidget line spacing issue (which also affected Path Browser. I changed to 'patch needed' because the current one in insufficient. I will take a look at the code.

    @terryjreedy
    Copy link
    Member

    In the Shell, Module Browser in Shell could open an Open Module box and then open both the module and browser. If one closes an editor window with an attached module browser, the module browser stays open. Double clicking re-opens an editor window.

    @python-dev
    Copy link
    Mannequin

    python-dev mannequin commented Oct 16, 2014

    New changeset 0f6209c3a968 by Terry Jan Reedy in branch '2.7':
    Issue bpo-16233: When the module browser is not invoked in an editor window with
    https://hg.python.org/cpython/rev/0f6209c3a968

    New changeset dd3c0ea52106 by Terry Jan Reedy in branch '3.4':
    Issue bpo-16233: When the module browser is not invoked in an editor window with
    https://hg.python.org/cpython/rev/dd3c0ea52106

    New changeset 14e62e632fbe by Terry Jan Reedy in branch 'default':
    Merge with 3.4 Issue#16233
    https://hg.python.org/cpython/rev/14e62e632fbe

    @terryjreedy
    Copy link
    Member

    Opening both a file and browser from Shell works nicely. I will leave renaming from Class Browser to Module Browser to another patch someday.

    @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
    Labels
    topic-IDLE type-bug An unexpected behavior, bug, or error
    Projects
    None yet
    Development

    No branches or pull requests

    1 participant