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
Comments
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 IDLE's help says: 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 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):
the case, as it seems). Thank you in advance for your attention. |
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." |
Attached is a quick patch to change the error message. |
IMO, Class Browser shouldn't even appear in PyShell. |
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 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. |
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. |
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. |
New changeset 0f6209c3a968 by Terry Jan Reedy in branch '2.7': New changeset dd3c0ea52106 by Terry Jan Reedy in branch '3.4': New changeset 14e62e632fbe by Terry Jan Reedy in branch 'default': |
Opening both a file and browser from Shell works nicely. I will leave renaming from Class Browser to Module Browser to another patch someday. |
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:
bugs.python.org fields:
The text was updated successfully, but these errors were encountered: