[PyKDE] Eric3 First impressions and questions

[Kirill Lapshin]

Detlev Offenbach wrote:

>Thanks, for your encouraging words.
>  
>
You are welcome. IMO, eric is much better then most commercial 
offerings. The only obstacle for making it the tool of choice in my 
company is Qt, PyQt licenses for windows platform. We'll have to figure 
it out with Trolltech and Riverbank. I guess in worst case we'll shell 
out money for BlackAdder just to get those licenses.

BTW, question to list: what is the easiest/cheapest way to run Eric on 
Windows?

>>1. For some reason profile and coverage statistics does not work for
>>me. They run but don't show any reports. Right click on source file ->
>>"Show" submenu has "Code coverage" and "Profile data" entries but they
>>    
>>
>
>Are there files ending in '.profile' or '.coverage' located in the 
>directory of the file? Did you run them on the script or on the project? 
>Maybe you can send a testfile and step by step instructions on how to 
>reproduce the problem.
>  
>
Yes, files with .profile, .timing and .coverage got created. Try to use 
attached test.e3p and test.py.

1. Open test.e3p project
2. Open (double click) test.py
3. Right click on editor pane, select Show submenu, notice that only 
"Code metrics" is active.
4. Run script (RS from toolbar), you'll get typical unittest output "Ran 
1 test".
5. Profile script (PS from toolbar), you'll get "Ran 0 tests" output. 
(this operation creates test.profile and test.timings files)
6. Right click on editor pane, select Show submenu, notice that only 
"Code metrics" is active.
7. Run coverage report on script (CS from toolbar), you'll get "Ran 1 
test" output. (this operation creates test.coverage file)
8. Right click on editor pane, select Show submenu, notice that only 
"Code metrics" is active.

Note: it is likely to be a problem with project file. When script ran 
outside of a project everything works fine.

While looking into this, I notices another bug (?). Try to create new 
project, select main folder, enter name, enter main script (all 
folders/files selected via file selector, not typed in). Hit Ok. New 
project gets created, but it does not have any files in it. I would 
expect to see script, which I selected as Main script, to be 
automatically added to project.

I am using Debian unstable. Python 2.3.3, Eric 3.4.1

>>are inactive. Another weird thing is that when I am trying to profile
>>my unittest I get "0 tests run" in the report. Tests set up in usual
>>way
>>
>>if __name__=='__main':
>>    unittest.main()
>>    
>>
>
>Please send a little test script showing this behavior.
>  
>
See above.

>>2. There are quite a lot of small annoyances with keyboard shortcuts.
>>I am an emacs user, so I wanted to customize shortcuts to be close to
>>emacs'. Obvious shortcoming is that there are no double keystrokes
>>(e.g. C-X C-S). That's probably not that easy to implement, oh well.
>>    
>>
>
>I'll look into this but won't promise anything.
>  
>
Yeah, I understand this. It certainly looks like more then few lines of 
code, while probably not so many customers really need it.

>>Even more annoying is that certain commands are not configurable. For
>>example there is no way to change "Go to line" keystroke. Alt-BS
>>performs undo, even though it is not listed as a registered
>>combination for Undo. I tried to assign Alt-BS to delete word on the
>>left, and shortcut configuration dialog allowed me to do that, but
>>Alt-BS still does undo. I am sure there are more things like this,
>>that's just something I noticed in first couple of hours.
>>    
>>
>
>That's a bug which needs fixing.
>  
>

Ok, I'll report more shortcut weirdness if I see it.

>>3. Too many common operations launch dialogs. I would really love to
>>be able to run script without answering questions about command line
>>arguments and working dir. Well, for run script there is such
>>alternative -- restart script, but for example for UnitTests I see no
>>    
>>
>
>Actually, restart script restarts the last debugger related command, i.e. 
>run, debug, coverage or profile, but not unittest. However, due to the 
>fact, that unittest is a separate dialog, which remembers the last 
>invocation until you quit eric3, it is simply a matter of changing to 
>the unittest dialog and press the start button again.
>  
>
Oh I see. So how about having separate set of shortcuts to run "Run 
Script", "Profile script" etc, bypassing dialog box? In fact I guess 
only Run script really needs , other operations are not that common... 
Moreover if I could somehow convince you to streamline unittesting -- 
implement one keystroke unittesting -- I would not need a shortcut even 
for run script, not sure about other users though.

>>way to run tests with a single key. BTW, while we are at it, it would
>>be really nice to make unittest screen a dockable panel rather than
>>separate window.
>>    
>>
>
>This was done intentionally because unittest can be started as a 
>standalone application as well, i.e. without starting the eric3 IDE.
>  
>

I see. Let me try to convince you that one way or another it is really 
important to be able to run tests fast, preferably with a single keystroke.

The whole idea of test driven development (extreme programming, agile 
programming, put you favorite test driven methodology here) is "test 
early, test often". Ideally you want to be able to write a single line 
of code and run tests, write another line, run them again. Of course 
development is not always done in such baby steps, but it is important 
to have such an ability. Now in current eric setup hitting keyboard 
shortcut for unittests (or clicking UT icon on toolbar) does not bring 
unit testing window up if it was already open. When you get to that 
window, hitting Enter does not run tests (while enter in run script 
dialog works), so you have to either use mouse to click Start button, or 
hit Alt-S. The best I can do at the moment is to use Alt-Tab (to switch 
to unittests) then Alt-S to run them. That works only if I haven't 
switched to any other windows in meantime (or I have to alt-tab more 
then once), and only if I want to run unit tests on the same script as 
before. But even in this case necessity to switch between windows is 
rather annoying, discouraging me from running tests as often as I want 
to. So my current solution is to use "Restart script" for unit testing.

Lets pause for a second and review possible ways to arrange unittests in 
a big project. One way is to put test code into the same file as project 
code. IOW, tests for functionality implemented in file foo.py lives in 
foo.py and ran via classical trick:

if __name__=='__main__':
    unittest.main()

To support this naive style we need an ability to run unittests on 
current open script with a single key. As a compromise special key to 
bring unittesting dialog and set script to current open script. Or maybe 
rework unittesting dialog a bit to have two options: run current script 
open in eric, or run arbitrary script. This way shortcut may be named 
"run unittests with last used settings". BTW, am I overlooking 
something, or is it really impossible to record macros operating on 
unittest dialog?

Alternatively, one can opt for putting test code in separate files. For 
example testfoo.py will have tests for foo.py. In this setup ideally IDE 
should allow associate test script with every python script. This sounds 
like a lot more work, but it will ultimately solve all unittesting problems.

Apart from running unittests on current script, the whole project can be 
tested periodically (before commit to source control for example). So 
another nice addition to unittesting functionality would be to have 
"Unittest script" and "Unittest project". The latter one can be 
implemented either via running the same Main script as all other "* 
project" operation do, or, to allow more flexibility, have a "Main 
testing script".

Thanks again for such a nice product. Don't be discouraged by my 
unittest ranting -- I really like eric a lot. I am simply trying to show 
what could be done to make it even better.

--Kirill


-------------- next part --------------
A non-text attachment was scrubbed...
Name: test.e3p
Type: text/xml
Size: 488 bytes
Desc: not available
Url : http://www.riverbankcomputing.com/pipermail/pyqt/attachments/20040427/292cd286/test.xml
-------------- next part --------------
A non-text attachment was scrubbed...
Name: test.py
Type: text/x-python
Size: 261 bytes
Desc: not available
Url : http://www.riverbankcomputing.com/pipermail/pyqt/attachments/20040427/292cd286/test.py