[issue16233] IDLE: conceptual problems with *Class browser*

[Francisco Gracia]

New submission from Francisco Gracia:

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.

--
components: IDLE
messages: 172891
nosy: fgracia
priority: normal
severity: normal
status: open
title: IDLE: conceptual problems with *Class browser*
type: enhancement
versions: Python 3.3

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue16233] IDLE: conceptual problems with *Class browser*

[Terry J. Reedy]

Changes by Terry J. Reedy :


--
nosy: +serwy, terry.reedy

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue16233] IDLE: conceptual problems with *Class browser*

[Roger Serwy]

Roger Serwy added the comment:

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."

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue16233] IDLE: conceptual problems with *Class browser*

[Roger Serwy]

Roger Serwy added the comment:

Attached is a quick patch to change the error message.

--
keywords: +patch
Added file: http://bugs.python.org/file27666/message_fix.patch

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue16233] IDLE: conceptual problems with *Class browser*

[Ramchandra Apte]

Ramchandra Apte added the comment:

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

--
nosy: +Ramchandra Apte

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue16233] IDLE: conceptual problems with *Class browser*

[Terry J. Reedy]

Terry J. Reedy added the comment:

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.

--
stage:  -> patch review
type: enhancement -> behavior
versions: +Python 2.7, Python 3.4

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com