From tjreedy at udel.edu  Sat Jun  1 23:40:05 2013
From: tjreedy at udel.edu (Terry Jan Reedy)
Date: Sat, 01 Jun 2013 17:40:05 -0400
Subject: [Idle-dev] some interesting ideas from 'DrRacket' programming
	environment
In-Reply-To: <CALazOyycpqHR7T3PKeRbtubRKrYB6xJztp3HoFvA_z2i1gkApA@mail.gmail.com>
References: <CALazOyye1oagVeHDL_UgNYJf-os6RYwA0ob4sqUO2M7FvrmT9Q@mail.gmail.com>
	<CALazOyycpqHR7T3PKeRbtubRKrYB6xJztp3HoFvA_z2i1gkApA@mail.gmail.com>
Message-ID: <kodpmv$ja5$1@ger.gmane.org>

On 5/31/2013 1:14 PM, Tom M wrote:

> there are some useful ideas that might be worth adopting from an IDE
> for Scheme - 'DrRacket', which is used to teach programming design.
>
> https://class.coursera.org/programdesign-001/class

My daughter took such a class as her first university CS class, but 
having learned Python first, from me, did not especially like it. 
However, I thought then it might be a source of ideas in spite of some 
problems.

Keep in mind that
a) Idle is intended to be less 'ambitious' than other IDEs, include some 
other Python IDEs like IPython (and Sage?).
b) We are currently focused on fixing bugs, making small enhancements, 
and adding tests to find more bugs and prevent regressions. Tests are 
necessary for any big changes that could break behavior. I expect much 
of this will be done in a year.

> The most interesting idea is that it highlights any code that wasn't
> executed during a unit/doctest.
> So a developer/student can easily spot deadcode or code that needs to
> have test cases created.

This should be an extension (assuming that there is not one already) 
that adds a 'run test with trace and visual coverage feedback' menu 
item. Perhaps the extension could look at the bottom of the file for a 
doctest or unittest call, parse it, run the test with tracing turned on, 
get the trace report, and mark lines not in the report with red.

> An idea that seeing this feature inspired (due to at first mistaking
> the purpose of the feature) was to add the arrows showing program flow
> as used in LLVM with Clang static debugging.  So the user can trace
> through visually how the program is executing.

I never saw this. The Idle debugger will let one follow program 
execution. It was recently fixed to work right on Windows. I found the 
equivalent Racket debugger to be harder to follow.

> Other useful features of the language/IDE for teaching purposes were
> having the file editor and evaluation window in single frame.  This is
> easier for many individuals than moving the file editor window
> to the foreground, then the evaluation window to the foreground and
> likely reduces 'context switching' mental overhead.

I already have the vision of Idle running in one OS window with 
side-by-side tabbed frames so one could look at two code files or code 
and shell simultaneously, side-by-side.

> Also something fairly unique, but quite interesting for simplifying
> teaching tasks, is the abilty to paste images into a variable
> definition, and able to output images to the evaluation window. i
> thought this was rather clever, pasting an actual image inline into
> your program file rather than path manipulation is likely drastically
> easier for new users, and visual results are both more interesting and
> often easier to understand.

I liked this feature. There are two issues: creating image objects by 
pasting; and displaying an image object as an graphics image instead of 
something semi-useless like the text string <class Image(xljdj) instance 
at 0X23a53de>. Unfortunately, Python is text, not image oriented. The 
stdlib does not have an image library and tk does not handle modern 
image formats. I do have the impression that tk text widgets can contain 
images.

Anything like this would take the Idle shell well beyond imitating the 
official console text shell. There might be issues with that.

> Along with the image pasting into variable definitons was the
> inclusion of a simple image manipulation library that allowed simple
> operations - enough to create toy games, and animations.  To me this
> is more kid friendly and appealing than turtle.

I agree. The big project of my daughter's class, after the classical 
algorithm exercises, was a simple game.

> Perhaps turtle could
> be extended to include the functions provided or a seperate module.

I think what is needed is a new tkinter subpackage for animated canvas 
sprites, with animation driven by the tkinter event loop. (Perhaps this 
exists somewhere already.)

The current turtle is actually turtle2 and has unsolved bugs. It was 
written (and not too well in my reading) to potentially run in any 
graphics framework. So turtles are isolated from a tkinter canvas by 
multiple layers that slow performance. Turtle is also single-sprite 
(turtle) oriented, while most games need multiple sprites (at least a 
ball and paddle or monkey and punching glove ;-).

> It allows for simple examples that are likely more readily graspable
> for beginners.  Ie one of the early examples in the course is a
> stoplight and turning the 3 colors off and on.

Animated graphics are also useful for showing algorithms in actions. I 
have seen some on Youtube for sorting algorithms.

> Have a look at these videos for the course
>
> 8 minutes onward in 01d
> 3:50 onward in 01e
> https://class.coursera.org/programdesign-001/wiki/view?page=AllLectures
>
> (might require free registration to view the videos)
>
> Thanks for your great work, hope you find these suggestions of interest.

Are there any ideas you are willing to work further on?

Terry



From cben at users.sf.net  Sun Jun  2 08:37:00 2013
From: cben at users.sf.net (Beni Cherniavsky-Paskin)
Date: Sat, 1 Jun 2013 23:37:00 -0700
Subject: [Idle-dev] some interesting ideas from 'DrRacket' programming
	environment
In-Reply-To: <CALazOyycpqHR7T3PKeRbtubRKrYB6xJztp3HoFvA_z2i1gkApA@mail.gmail.com>
References: <CALazOyye1oagVeHDL_UgNYJf-os6RYwA0ob4sqUO2M7FvrmT9Q@mail.gmail.com>
	<CALazOyycpqHR7T3PKeRbtubRKrYB6xJztp3HoFvA_z2i1gkApA@mail.gmail.com>
Message-ID: <CALJxei+wV=+qYB7LDtYG0CSpPPBBeXWwDmzvgFS2C1TMgf80DQ@mail.gmail.com>

On Fri, May 31, 2013 at 10:14 AM, Tom M <letterrip at gmail.com> wrote:

> Also something fairly unique, but quite interesting for simplifying
> teaching tasks, is the abilty to paste images into a variable
> definition, and able to output images to the evaluation window. i
> thought this was rather clever, pasting an actual image inline into
> your program file rather than path manipulation is likely drastically
> easier for new users, and visual results are both more interesting and
> often easier to understand.
>

On the IDE side, Sikuli <http://www.sikuli.org/> pretty much nailed this.
[http://doc.sikuli.org/globals.html#importingsikuliscripts has some info on
how it's implemented.]
I don't know if anybody ever used it for teaching for its inline image
support but unrelated to its GUI automation purpose...

-- 
Beni Cherniavsky-Paskin
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/idle-dev/attachments/20130601/3cf13f0d/attachment.html>

From webster.phil at gmail.com  Tue Jun  4 03:27:15 2013
From: webster.phil at gmail.com (Phil Webster)
Date: Mon, 3 Jun 2013 21:27:15 -0400
Subject: [Idle-dev] Introduction
Message-ID: <0A73EA8F-866E-4110-B040-7C6E56C8C1B4@gmail.com>

Hi everyone!

I'm new to the mailing list and wanted to introduce myself. My name is Phil and I'm entering my fourth year studying CS at Grand Valley State University. This summer I'll be working on improvements to IDLE as part of Google's Summer of Code Program. I'm excited to be part of a community that I've found to be friendly and helpful and look forward to contributing code over the next few months and beyond.

Best,

Phil Webster

From interstar at gmail.com  Tue Jun  4 05:40:28 2013
From: interstar at gmail.com (phil jones)
Date: Tue, 4 Jun 2013 00:40:28 -0300
Subject: [Idle-dev] Introduction
In-Reply-To: <0A73EA8F-866E-4110-B040-7C6E56C8C1B4@gmail.com>
References: <0A73EA8F-866E-4110-B040-7C6E56C8C1B4@gmail.com>
Message-ID: <CAP97Hnk-rNrsXLCh0irOuhLdxmq1zdMGbREh1yKoVGr=3FfDHw@mail.gmail.com>

Welcome Phil. :-)

(another) Phil

On 3 June 2013 22:27, Phil Webster <webster.phil at gmail.com> wrote:
> Hi everyone!
>
> I'm new to the mailing list and wanted to introduce myself. My name is Phil and I'm entering my fourth year studying CS at Grand Valley State University. This summer I'll be working on improvements to IDLE as part of Google's Summer of Code Program. I'm excited to be part of a community that I've found to be friendly and helpful and look forward to contributing code over the next few months and beyond.
>
> Best,
>
> Phil Webster
> _______________________________________________
> IDLE-dev mailing list
> IDLE-dev at python.org
> http://mail.python.org/mailman/listinfo/idle-dev

From ether.joe at gmail.com  Tue Jun  4 06:01:15 2013
From: ether.joe at gmail.com (Sean Felipe Wolfe)
Date: Mon, 3 Jun 2013 21:01:15 -0700
Subject: [Idle-dev] Introduction
In-Reply-To: <CAP97Hnk-rNrsXLCh0irOuhLdxmq1zdMGbREh1yKoVGr=3FfDHw@mail.gmail.com>
References: <0A73EA8F-866E-4110-B040-7C6E56C8C1B4@gmail.com>
	<CAP97Hnk-rNrsXLCh0irOuhLdxmq1zdMGbREh1yKoVGr=3FfDHw@mail.gmail.com>
Message-ID: <CAOFf2a2+jOwu692+JQjjx2HoyXvhytXZczO4N5k9e4_Hn11vOA@mail.gmail.com>

Welcome Phil! My family is in West Michigan ... beautiful part of the
world. Good luck with your studies =)

On Mon, Jun 3, 2013 at 8:40 PM, phil jones <interstar at gmail.com> wrote:
> Welcome Phil. :-)
>
> (another) Phil
>
> On 3 June 2013 22:27, Phil Webster <webster.phil at gmail.com> wrote:
>> Hi everyone!
>>
>> I'm new to the mailing list and wanted to introduce myself. My name is Phil and I'm entering my fourth year studying CS at Grand Valley State University. This summer I'll be working on improvements to IDLE as part of Google's Summer of Code Program. I'm excited to be part of a community that I've found to be friendly and helpful and look forward to contributing code over the next few months and beyond.
>>
>> Best,
>>
>> Phil Webster
>> _______________________________________________
>> IDLE-dev mailing list
>> IDLE-dev at python.org
>> http://mail.python.org/mailman/listinfo/idle-dev
> _______________________________________________
> IDLE-dev mailing list
> IDLE-dev at python.org
> http://mail.python.org/mailman/listinfo/idle-dev



-- 
A musician must make music, an artist must paint, a poet must write,
if he is to be ultimately at peace with himself.
- Abraham Maslow

From raajjya at gmail.com  Thu Jun  6 04:00:32 2013
From: raajjya at gmail.com (Jayakrishnan Rajagopalasarma)
Date: Thu, 6 Jun 2013 07:30:32 +0530
Subject: [Idle-dev] Introducing
Message-ID: <CAEniZVjbAbD2pj90gXW2RoMy4t6SeMFmMsN2dVm020sM=-tpDA@mail.gmail.com>

hi everyone,
I  am Jayakrishnan, started working on IDLE improvements project with
Google Summer of Code. Currently entering final year of Computer Science
Engineering at University of Moratuwa, SriLanka.

Not very new to this mailing list, but requested to introduce myself :)



.




*"Think big, Start Small, Move Fast"*
Thanks && Regards..
R. Jayakrishnan

<https://www.facebook.com/raajjya>  <http://123works.blogspot.com/>
<https://plus.google.com/u/0/114501383949013359988/posts>
  <http://www.linkedin.com/profile/view?id=92231015&trk=tab_pro>
<https://twitter.com/#!/raajjya>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/idle-dev/attachments/20130606/5a0f8f15/attachment.html>

From roger.serwy at gmail.com  Thu Jun  6 04:36:48 2013
From: roger.serwy at gmail.com (Roger Serwy)
Date: Wed, 05 Jun 2013 21:36:48 -0500
Subject: [Idle-dev] Introduction
In-Reply-To: <0A73EA8F-866E-4110-B040-7C6E56C8C1B4@gmail.com>
References: <0A73EA8F-866E-4110-B040-7C6E56C8C1B4@gmail.com>
Message-ID: <51AFF5C0.7040709@gmail.com>

Welcome Phil!

On 06/03/2013 08:27 PM, Phil Webster wrote:
> Hi everyone!
>
> I'm new to the mailing list and wanted to introduce myself. My name is Phil and I'm entering my fourth year studying CS at Grand Valley State University. This summer I'll be working on improvements to IDLE as part of Google's Summer of Code Program. I'm excited to be part of a community that I've found to be friendly and helpful and look forward to contributing code over the next few months and beyond.
>
> Best,
>
> Phil Webster
> _______________________________________________
> IDLE-dev mailing list
> IDLE-dev at python.org
> http://mail.python.org/mailman/listinfo/idle-dev


From roger.serwy at gmail.com  Thu Jun  6 04:37:08 2013
From: roger.serwy at gmail.com (Roger Serwy)
Date: Wed, 05 Jun 2013 21:37:08 -0500
Subject: [Idle-dev] Introducing
In-Reply-To: <CAEniZVjbAbD2pj90gXW2RoMy4t6SeMFmMsN2dVm020sM=-tpDA@mail.gmail.com>
References: <CAEniZVjbAbD2pj90gXW2RoMy4t6SeMFmMsN2dVm020sM=-tpDA@mail.gmail.com>
Message-ID: <51AFF5D4.2090802@gmail.com>

Welcome Jayakrishnan!

On 06/05/2013 09:00 PM, Jayakrishnan Rajagopalasarma wrote:
> hi everyone,
> I  am Jayakrishnan, started working on IDLE improvements project with 
> Google Summer of Code. Currently entering final year of Computer 
> Science Engineering at University of Moratuwa, SriLanka.
>
> Not very new to this mailing list, but requested to introduce myself :)
>
>
>
> .
>
>
>
>
> */"Think big, Start Small, Move Fast"/*
> Thanks && Regards..
> R. Jayakrishnan
>
> <https://www.facebook.com/raajjya> <http://123works.blogspot.com/> 
> <https://plus.google.com/u/0/114501383949013359988/posts> 
> <http://www.linkedin.com/profile/view?id=92231015&trk=tab_pro> 
> <https://twitter.com/#%21/raajjya>
>
>
>
>
> _______________________________________________
> IDLE-dev mailing list
> IDLE-dev at python.org
> http://mail.python.org/mailman/listinfo/idle-dev

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/idle-dev/attachments/20130605/5a6c2f72/attachment.html>

From webster.phil at gmail.com  Tue Jun 11 20:14:27 2013
From: webster.phil at gmail.com (Phil webster)
Date: Tue, 11 Jun 2013 14:14:27 -0400
Subject: [Idle-dev] Stats for idlelib
Message-ID: <CALmA3g6tB8aZrWkC9gU6QmRKAyRDx8nkSK_m0ngibdGDLnA9Rw@mail.gmail.com>

Hi All,

As Jayakrishnan and I prepare to work on unittests for
IDLE<http://bugs.python.org/issue15392>,
we have created a spreadsheet with some basic info for each of the modules
in Lib/idlelib. If you're interested, you can take a look at it
here<https://docs.google.com/spreadsheet/ccc?key=0AqHo248BJw3RdFRnREo5TGtrQmxvQi1oem1HUS1PNGc&usp=sharing>
.

Phil
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/idle-dev/attachments/20130611/0cc3d85b/attachment.html>

From michaelklein4685 at outlook.com  Tue Jun 11 13:59:17 2013
From: michaelklein4685 at outlook.com (Michael Klein)
Date: Tue, 11 Jun 2013 16:29:17 +0430
Subject: ADALSINDO JOĆO CARLOS MOREIRA DE CARVALHO ARAUJO 
Message-ID: <13709676734dbfc76aeb142e165e96c7a9739e0818@outlook.com>

GRENTESKI KAROLINE PONTES CAVALCANTE MANGUINHO, EDSON SILVA DE ARAUJO, JO?O CARLOS MOREIRA DE CARVALHO, ROS?NGELA MARIA DE AMORIM, IRANI DE SOUZA BARBOSA, N?DIA REGINA DOS P., VALMI MANUEL DA SILVA, FABIO NOGUEIRA DA SILVA. PEDRO SIQUEIRA FONTENELE. AMINADABE CONST?NCIO, ELIANO LEITE, LEITE CRISTIANO, CONST?NCIO ADALSINDO LEITE.

ELIANO GRENTESKI, TONY VERMONT, JACQUES LAG?A, MURILO ELBAS, DALTON VIGH, RENATO BORGHI, FERNANDO RESKI, LUDOVAL CAMPOS, ARY FRAN?A, RUI RICARDO DIAS, GUILHERME WEBER, MARCO LUQUE, CARLOS GREG?RIO, PAULO CARVALHO, EDUARDO SEMERJIAN, JOS? STEINBERG, ALEXANDRE SLAVIERO AUXILIADORA, ADALBERTO. ARACRUZ, IPATINGA, GUAMAR? INGA?.

AMINADABE AUXILIADORA, ADALBERTO. ARACRUZ, IPATINGA, GUAMAR? JO?O CARLOS MOREIRA DE CARVALHO PALM?POLIS PEDRO SIQUEIRA FONTENELE BAQUI GRENTESKI, CONST?NCIO LEITE.


From roger.serwy at gmail.com  Wed Jun 12 05:35:46 2013
From: roger.serwy at gmail.com (Roger Serwy)
Date: Tue, 11 Jun 2013 22:35:46 -0500
Subject: [Idle-dev] Stats for idlelib
In-Reply-To: <CALmA3g6tB8aZrWkC9gU6QmRKAyRDx8nkSK_m0ngibdGDLnA9Rw@mail.gmail.com>
References: <CALmA3g6tB8aZrWkC9gU6QmRKAyRDx8nkSK_m0ngibdGDLnA9Rw@mail.gmail.com>
Message-ID: <51B7EC92.7040901@gmail.com>

Hi Phil,

That is a nice spreadsheet. Do you have any guidelines for using it?

Cheers,
Roger

On 06/11/2013 01:14 PM, Phil webster wrote:
> Hi All,
>
> As Jayakrishnan and I prepare to work on unittests for IDLE 
> <http://bugs.python.org/issue15392>, we have created a spreadsheet 
> with some basic info for each of the modules in Lib/idlelib. If you're 
> interested, you can take a look at it here 
> <https://docs.google.com/spreadsheet/ccc?key=0AqHo248BJw3RdFRnREo5TGtrQmxvQi1oem1HUS1PNGc&usp=sharing>.
>
> Phil
>
>
> _______________________________________________
> IDLE-dev mailing list
> IDLE-dev at python.org
> http://mail.python.org/mailman/listinfo/idle-dev

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/idle-dev/attachments/20130611/a3dc8a7e/attachment.html>

From gberhanu1974 at gmail.com  Wed Jun 12 13:45:02 2013
From: gberhanu1974 at gmail.com (Getachew Shomorro)
Date: Wed, 12 Jun 2013 04:45:02 -0700
Subject: [Idle-dev] (no subject)
Message-ID: <CAGpu-zF-b6CxzmTakr4nki+WEPkUD9QY_JZz=W+a7zOXao2wQw@mail.gmail.com>

I want to join the mailing list
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/idle-dev/attachments/20130612/7f361e8e/attachment.html>

From tjreedy at udel.edu  Wed Jun 12 21:32:55 2013
From: tjreedy at udel.edu (Terry Reedy)
Date: Wed, 12 Jun 2013 15:32:55 -0400
Subject: [Idle-dev] (no subject)
In-Reply-To: <CAGpu-zF-b6CxzmTakr4nki+WEPkUD9QY_JZz=W+a7zOXao2wQw@mail.gmail.com>
References: <CAGpu-zF-b6CxzmTakr4nki+WEPkUD9QY_JZz=W+a7zOXao2wQw@mail.gmail.com>
Message-ID: <51B8CCE7.5060301@udel.edu>

On 6/12/2013 7:45 AM, Getachew Shomorro wrote:
> I want to join the mailing list

To subscribe, go to
http://mail.python.org/mailman/listinfo/idle-dev

One can also read and post via the newsgroup mirror (as I do)

news.gmane.org, group 'gmane.comp.python.idle'

-- 
Terry Jan Reedy
-- 
Terry Jan Reedy


From tjreedy at udel.edu  Thu Jun 13 07:32:46 2013
From: tjreedy at udel.edu (Terry Reedy)
Date: Thu, 13 Jun 2013 01:32:46 -0400
Subject: [Idle-dev] Idle Testing: Recent Thoughts, mock_tk
Message-ID: <kpblhp$nes$1@ger.gmane.org>

With other people working on Idle tests, I want to share my recent 
experience. (Some of this should go in idle_test.README.txt or another 
doc, when I have time.)

Idle tests are written with the unittest module, to be runnable with 
unittest.main. This mean no test_main() function (part of the older 
regrtest system), which is being removed from older test modules. (Over 
10 were changed in just the last day.)

Idle functions and class methods mostly focus on either creating or 
operating  gui or on non-gui calculations. This suggests gui tests for 
the first and non-gui for the latter. The problem is that non-gui 
methods can use gui-elements, which make the test a gui-using test 
unless they are replaced with mocks.

For instance, configSectionNameDialog.GetCfgSectionNameDialog.name_ok 
(altered spelling) checks user input and returns the stripped version. 
It gets the input from a StringVar and displays error messages with 
tkMessageBox.showerror. A messagebox is obvious a gui element, but so 
are Variable subclass instances, because they require a Tk master 
object. (Since Variables are not visible widgets, this surprised me).

Module mock_tk, used in test_name_dialog, has replacements for Variables 
and messageboxes. See the patch for issue 18130 or the new files in 
idle_test. Since tkMessageBox is a configSectionNameDialog global name 
(bound to a module), it is replaced in the module itself (for the 
duration of the test) by a mock messagebox, whose instances simply 
record the inputs for later examination. (This is colloquially called 
monkeypatching.) The fact that module functions and class methods can be 
accessed and called the same way means the module can be replaced by a 
class.

The StringVar accessed by name_ok is an instance attribute. So it is 
replaced by its mock in the dummy class defined in the test module. The 
dummy class provides a gui-free environment with the minimum attributes 
needed for the function to operate and be tested. Python makes this all 
easier than I expected.

I have a patch that does something similar for one of the three 
calculation methods in GrepDialog.GrepDialog. I hope to apply it soon, 
along with tests for the other two.

 From 18104: Idle: make human-mediated GUI tests usable
"23 of the 62 idlelib/*.py files have an 'if __name__ ...' test that 
brings up a tkinter gui widget and waits for the human tester to do ... 
something." The work on configSectionNameDialog started with getting its 
'test' to run and then deciding on and writing minimal instructions for 
actually testing it. That lead to automation of much of the checking. 
The residual minimum for humans is to check the visual appearance. For 
instance, the buttons were not centered until I removed the 'uncenter' 
argument.

18103: Create a GUI test framework for Idle; needs more work

-- 
Terry Jan Reedy


From rovitotv at gmail.com  Thu Jun 13 18:42:12 2013
From: rovitotv at gmail.com (Todd V. Rovito)
Date: Thu, 13 Jun 2013 12:42:12 -0400
Subject: [Idle-dev] Idle Testing: Recent Thoughts, mock_tk
In-Reply-To: <kpblhp$nes$1@ger.gmane.org>
References: <kpblhp$nes$1@ger.gmane.org>
Message-ID: <CE27A8FB-76F9-4AA3-BD9E-A587E91A1399@gmail.com>


On Jun 13, 2013, at 1:32 AM, Terry Reedy <tjreedy at udel.edu> wrote:

> With other people working on Idle tests, I want to share my recent experience. (Some of this should go in idle_test.README.txt or another doc, when I have time.)
This email is very helpful, thanks for taking the time to write it.

> 
> Idle tests are written with the unittest module, to be runnable with unittest.main. This mean no test_main() function (part of the older regrtest system), which is being removed from older test modules. (Over 10 were changed in just the last day.)
> 
> Idle functions and class methods mostly focus on either creating or operating  gui or on non-gui calculations. This suggests gui tests for the first and non-gui for the latter. The problem is that non-gui methods can use gui-elements, which make the test a gui-using test unless they are replaced with mocks.
> 
> For instance, configSectionNameDialog.GetCfgSectionNameDialog.name_ok (altered spelling) checks user input and returns the stripped version. It gets the input from a StringVar and displays error messages with tkMessageBox.showerror. A messagebox is obvious a gui element, but so are Variable subclass instances, because they require a Tk master object. (Since Variables are not visible widgets, this surprised me).
> 
> Module mock_tk, used in test_name_dialog, has replacements for Variables and messageboxes. See the patch for issue 18130 or the new files in idle_test. Since tkMessageBox is a configSectionNameDialog global name (bound to a module), it is replaced in the module itself (for the duration of the test) by a mock messagebox, whose instances simply record the inputs for later examination. (This is colloquially called monkeypatching.) The fact that module functions and class methods can be accessed and called the same way means the module can be replaced by a class.
I looked at issue 18130 closely and it mostly makes sense to me but I was surprised you didn't use unittest.mock in mock_tk.  Does that mean I can assume for other unit tests that we shouldn't use unittest.mock and monkey patching without mock is ok? Using mock in the past seems like it would give us more options than monkey patching.    

Thanks!



From tjreedy at udel.edu  Fri Jun 14 01:02:19 2013
From: tjreedy at udel.edu (Terry Reedy)
Date: Thu, 13 Jun 2013 19:02:19 -0400
Subject: [Idle-dev] Idle Testing: Recent Thoughts, mock_tk
In-Reply-To: <CE27A8FB-76F9-4AA3-BD9E-A587E91A1399@gmail.com>
References: <kpblhp$nes$1@ger.gmane.org>
	<CE27A8FB-76F9-4AA3-BD9E-A587E91A1399@gmail.com>
Message-ID: <kpdj1n$gjd$1@ger.gmane.org>

On 6/13/2013 12:42 PM, Todd V. Rovito wrote:
>
> On Jun 13, 2013, at 1:32 AM, Terry Reedy <tjreedy at udel.edu> wrote:

>> For instance,
>> configSectionNameDialog.GetCfgSectionNameDialog.name_ok (altered
>> spelling) checks user input and returns the stripped version. It
>> gets the input from a StringVar and displays error messages with
>> tkMessageBox.showerror. A messagebox is obvious a gui element, but
>> so are Variable subclass instances, because they require a Tk
>> master object. (Since Variables are not visible widgets, this
>> surprised me).
>>
>> Module mock_tk, used in test_name_dialog, has replacements for
>> Variables and messageboxes. See the patch for issue 18130 or the
>> new files in idle_test. Since tkMessageBox is a
>> configSectionNameDialog global name (bound to a module), it is
>> replaced in the module itself (for the duration of the test) by a
>> mock messagebox, whose instances simply record the inputs for later
>> examination. (This is colloquially called monkeypatching.) The fact
>> that module functions and class methods can be accessed and called
>> the same way means the module can be replaced by a class.

This test module is based on both thought and experiment. Here is the 
thought part. A method uses three namespaces: local, attribute, and 
module global. A different procedure is needed for each to affect what 
the method reads (setup) and read what the method does (test).

We affect the local namespace by passing arguments but do not directly 
change bindings in the body; we then look at the return.

We can control the part of the attribute namespace that a method reads 
by embedding the method in a customized dummy (or mock) version of its 
class. (Because Python methods are functions, this is trivial. For 2.7, 
'.im_func' must be added.) We can similarly read attributes to see what 
change the method made.

Because func.__globals__ is read-only, we can only change what the 
method sees by patching the module in which it is defined. But we 
generally only need to replace imported gui objects, like 
tkinter.messagebox (tkMessageBox).

> I looked at issue 18130 closely and it mostly makes sense to me

I hope the above explains it even better.

> but I was surprised you didn't use unittest.mock in mock_tk.

Given how easy it was to do what I laid out above, I did not see any 
need to re-investigate mock at the time that I wrote that test. "Do the 
minimun needed to make the test pass." The next test, test_grep, has not 
required anything new.

Before mock was added, I read both the doc chapter and the howto. What I 
remember is that it is a pretty heavy-duty module for heavy-duty 
problems and too much to absorb and master in an afternoon. I have never 
used it.

 > Does that mean I can assume for other unit tests that we shouldn't
 > use unittest.mock

No. It means that if I apply a patch, I would like there to be a reason 
to use it beyond the fact that it exists: like readability or 
performance increase.

Analogy: itertools is a great module, but I do not necessarily use it 
every time I possibly could. And I am more comfortable using builtin and 
itertools iterators after having written and run some myself, so I 
understand their  operation.

 > and monkey patching without mock is ok?

It is ok with me. Why not?

I was cognizant of the need to restore the module before exiting the 
test. While probably not needed for this module for the test suite, 
restoration *is* needed to run the human gui-visible test after the 
automated test. (And if a test were to patch a module such as Editor 
that is used in many tests, restoration would be needed even for testing.)

The regrtest test runner treats test modules as the unit for test order 
randomization and parallelization with multiple processses. If 
Test_class.test_method were the unit for such, then a with statement 
wrapping the body of a method would be better than what I did.

> Using mock in the past seems like it would give us more options than monkey
> patching.

I imagine it does ;-). If you want, suggest improvements based on your 
experience.

-- 
Terry Jan Reedy


From webster.phil at gmail.com  Fri Jun 14 03:56:47 2013
From: webster.phil at gmail.com (Phil webster)
Date: Thu, 13 Jun 2013 21:56:47 -0400
Subject: [Idle-dev] Stats for idlelib
In-Reply-To: <51B7EC92.7040901@gmail.com>
References: <CALmA3g6tB8aZrWkC9gU6QmRKAyRDx8nkSK_m0ngibdGDLnA9Rw@mail.gmail.com>
	<51B7EC92.7040901@gmail.com>
Message-ID: <CALmA3g7z=uvGEhtxkH6EDMrMNP8ZVyf_mst8QggtJn1tPooRKA@mail.gmail.com>

Hi Roger,

I just added status and contributor columns and made the spreadsheet
editable by anyone. This way everyone can see what is being worked on and
we are less likely to duplicate work. I'm also realizing that the
GUI/non-GUI classification may not be very accurate (at least for
RstripExtension.py), but will leave it in for now.

Phil


On Tue, Jun 11, 2013 at 11:35 PM, Roger Serwy <roger.serwy at gmail.com> wrote:

>  Hi Phil,
>
> That is a nice spreadsheet. Do you have any guidelines for using it?
>
> Cheers,
> Roger
>
>
> On 06/11/2013 01:14 PM, Phil webster wrote:
>
> Hi All,
>
>  As Jayakrishnan and I prepare to work on unittests for IDLE<http://bugs.python.org/issue15392>,
> we have created a spreadsheet with some basic info for each of the modules
> in Lib/idlelib. If you're interested, you can take a look at it here<https://docs.google.com/spreadsheet/ccc?key=0AqHo248BJw3RdFRnREo5TGtrQmxvQi1oem1HUS1PNGc&usp=sharing>
> .
>
>  Phil
>
>
> _______________________________________________
> IDLE-dev mailing listIDLE-dev at python.orghttp://mail.python.org/mailman/listinfo/idle-dev
>
>
>
> _______________________________________________
> IDLE-dev mailing list
> IDLE-dev at python.org
> http://mail.python.org/mailman/listinfo/idle-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/idle-dev/attachments/20130613/9266864e/attachment.html>

From rovitotv at gmail.com  Sun Jun 16 00:39:59 2013
From: rovitotv at gmail.com (Todd V. Rovito)
Date: Sat, 15 Jun 2013 18:39:59 -0400
Subject: [Idle-dev] Stats for idlelib
In-Reply-To: <CALmA3g7z=uvGEhtxkH6EDMrMNP8ZVyf_mst8QggtJn1tPooRKA@mail.gmail.com>
References: <CALmA3g6tB8aZrWkC9gU6QmRKAyRDx8nkSK_m0ngibdGDLnA9Rw@mail.gmail.com>
	<51B7EC92.7040901@gmail.com>
	<CALmA3g7z=uvGEhtxkH6EDMrMNP8ZVyf_mst8QggtJn1tPooRKA@mail.gmail.com>
Message-ID: <B383B5A8-1BB7-4E1B-A9F6-0F9FDC347387@gmail.com>

Thanks Phil,  I just opened an issue on bugs.python.org and indicated that next to FormatParagrah.py so people know I am working on the unit test.  I too am hopefully this will prevent duplication of work.  Thanks!

On Jun 13, 2013, at 9:56 PM, Phil webster <webster.phil at gmail.com> wrote:

> Hi Roger,
> 
> I just added status and contributor columns and made the spreadsheet editable by anyone. This way everyone can see what is being worked on and we are less likely to duplicate work. I'm also realizing that the GUI/non-GUI classification may not be very accurate (at least for RstripExtension.py), but will leave it in for now.
> 
> Phil
> 
> 
> On Tue, Jun 11, 2013 at 11:35 PM, Roger Serwy <roger.serwy at gmail.com> wrote:
> Hi Phil,
> 
> That is a nice spreadsheet. Do you have any guidelines for using it?
> 
> Cheers,
> Roger
> 
> 
> On 06/11/2013 01:14 PM, Phil webster wrote:
>> Hi All,
>> 
>> As Jayakrishnan and I prepare to work on unittests for IDLE, we have created a spreadsheet with some basic info for each of the modules in Lib/idlelib. If you're interested, you can take a look at it here.
>> 
>> Phil
>> 
>> 
>> _______________________________________________
>> IDLE-dev mailing list
>> IDLE-dev at python.org
>> http://mail.python.org/mailman/listinfo/idle-dev
> 
> 
> _______________________________________________
> IDLE-dev mailing list
> IDLE-dev at python.org
> http://mail.python.org/mailman/listinfo/idle-dev
> 
> 
> _______________________________________________
> IDLE-dev mailing list
> IDLE-dev at python.org
> http://mail.python.org/mailman/listinfo/idle-dev

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/idle-dev/attachments/20130615/6bf61a32/attachment.html>

From tjreedy at udel.edu  Sun Jun 23 00:54:06 2013
From: tjreedy at udel.edu (Terry Reedy)
Date: Sat, 22 Jun 2013 18:54:06 -0400
Subject: [Idle-dev] TestCase subclass names; changing template
Message-ID: <kq59uf$oif$1@ger.gmane.org>

In README.txt, I had the template use

class Test_x(unittest.TextCase);

In reviewing existing test/test_xxx.py files, I see mostly AbcTestCase, 
AbcTests, and AbcTest, but only rarely TestAbc or Abc. I thought of 
going with no prefix or suffix, but that is almost exclusively used used 
for classes that are *not* TestCase subclasses. So I decided to go with 
the flow and use the 'Test' suffix in test_grep (just committed) and 
will change the template. This is what R.J. did with PathBrowserTest. I 
will change existing test files when I revisit them anyway.

-- 
Terry Jan Reedy