Created on 2012-10-14 15:52 by fgracia, last changed 2014-10-16 02:05 by terry.reedy. This issue is now closed.
|message_fix.patch||roger.serwy, 2012-10-23 02:39||review|
|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) *||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) *||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) *||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) *||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) *||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)||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) *||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.
|2014-10-16 02:05:02||terry.reedy||set||status: open -> closed|
messages: + msg229509
stage: needs patch -> resolved
messages: + msg229508
|2014-10-15 22:45:39||terry.reedy||set||messages: + msg229506|
stage: patch review -> needs patch
|2014-10-03 03:45:26||terry.reedy||set||versions: + Python 3.5, - Python 3.3|
|2013-02-21 21:58:58||terry.reedy||set||type: enhancement -> behavior|
stage: patch review
messages: + msg182611
versions: + Python 2.7, Python 3.4
|2013-02-21 13:16:35||Ramchandra Apte||set||nosy:
+ Ramchandra Apte|
messages: + msg182593
keywords: + patch
messages: + msg173578
|2012-10-23 02:35:44||roger.serwy||set||messages: + msg173577|
+ terry.reedy, roger.serwy|