This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

classification
Title: IDLE: conceptual problems with *Class browser*
Type: behavior Stage: resolved
Components: IDLE Versions: Python 3.4, Python 3.5, Python 2.7
process
Status: closed Resolution: fixed
Dependencies: Superseder:
Assigned To: Nosy List: Ramchandra Apte, fgracia, python-dev, roger.serwy, terry.reedy
Priority: normal Keywords: patch

Created on 2012-10-14 15:52 by fgracia, last changed 2022-04-11 14:57 by admin. This issue is now closed.

Files
File name Uploaded Description Edit
message_fix.patch roger.serwy, 2012-10-23 02:39 review
Messages (9)
msg172891 - (view) Author: Francisco Gracia (fgracia) Date: 2012-10-14 15:52
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.
msg173577 - (view) Author: Roger Serwy (roger.serwy) * (Python committer) Date: 2012-10-23 02:35
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."
msg173578 - (view) Author: Roger Serwy (roger.serwy) * (Python committer) Date: 2012-10-23 02:39
Attached is a quick patch to change the error message.
msg182593 - (view) Author: Ramchandra Apte (Ramchandra Apte) * Date: 2013-02-21 13:16
IMO, Class Browser shouldn't even appear in PyShell.
msg182611 - (view) Author: Terry J. Reedy (terry.reedy) * (Python committer) Date: 2013-02-21 21:58
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.
msg229504 - (view) Author: Terry J. Reedy (terry.reedy) * (Python committer) Date: 2014-10-15 22:25
I opened #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.
msg229506 - (view) Author: Terry J. Reedy (terry.reedy) * (Python committer) Date: 2014-10-15 22:45
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.
msg229508 - (view) Author: Roundup Robot (python-dev) (Python triager) Date: 2014-10-16 02:02
New changeset 0f6209c3a968 by Terry Jan Reedy in branch '2.7':
Issue #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 #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
msg229509 - (view) Author: Terry J. Reedy (terry.reedy) * (Python committer) Date: 2014-10-16 02:05
Opening both a file and browser from Shell works nicely.  I will leave renaming from Class Browser to Module Browser to another patch someday.
History
Date User Action Args
2022-04-11 14:57:37adminsetgithub: 60437
2014-10-16 02:05:02terry.reedysetstatus: open -> closed
resolution: fixed
messages: + msg229509

stage: needs patch -> resolved
2014-10-16 02:02:52python-devsetnosy: + python-dev
messages: + msg229508
2014-10-15 22:45:39terry.reedysetmessages: + msg229506
2014-10-15 22:25:10terry.reedysetmessages: + msg229504
stage: patch review -> needs patch
2014-10-03 03:45:26terry.reedysetversions: + Python 3.5, - Python 3.3
2013-02-21 21:58:58terry.reedysettype: enhancement -> behavior
stage: patch review
messages: + msg182611
versions: + Python 2.7, Python 3.4
2013-02-21 13:16:35Ramchandra Aptesetnosy: + Ramchandra Apte
messages: + msg182593
2012-10-23 02:39:06roger.serwysetfiles: + message_fix.patch
keywords: + patch
messages: + msg173578
2012-10-23 02:35:44roger.serwysetmessages: + msg173577
2012-10-19 18:43:52terry.reedysetnosy: + terry.reedy, roger.serwy
2012-10-14 15:52:29fgraciacreate