From saimadhavheblikar at gmail.com  Tue May  6 15:23:06 2014
From: saimadhavheblikar at gmail.com (Saimadhav Heblikar)
Date: Tue, 6 May 2014 18:53:06 +0530
Subject: [Idle-dev] Ability to integrate 3rd party code checker into IDLE
Message-ID: <CAO3PiBiB_WUVDT7iY5cnnKJiPSHf7Seoet_WcJT-uCu+OYQCqA@mail.gmail.com>

Hi,
I am posting an initial design plan to be able to integrate 3rd party code
checker's into IDLE.


1. UI Part
OutputWindow already has a 'goto file/line' feature, where a user can open
a file/line. This feature will be used. Depending on the 3rd party api,
there may be a need to reformat the results to match the regular
expressions of OutputWindow. Some issues like ensuring the file path is
present in the output of the 3rd party checker must be handled on a
case-to-case basis.

2.Working logic
Each 3rd party api will store its settings(IDLE related) in the same way as
extension config is stored currently(config-extensions.def), but, obviously
in a different file, meant exclusively for storing the settings for 3rd
party api settings.
It could contain details like whether it is enabled, the path/file to call
the api, the arguments to be passed etc. It could also have the details of
the function to be called if there is need for reformatting.
The location and name of the config file is to be discussed.

With these settings in place, subprocess.Popen will be used to run the 3rd
party code checker and send the result to an OutputWindow instance
with/without reformattting.

http://bugs.python.org/issue3068 provides option to modify config via GUI.
This could be used for the current purpose as well.

While we could add support for as many 3rd party code checkers, there is a
need to document the process to enable others to integrate their
extensions. This will be done once things are ready.
If i missed out something i will reply to this thread.


Looking forward to your comments and feedback.

Regards
Saimadhav Heblikar
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/idle-dev/attachments/20140506/f9d3359a/attachment.html>

From tjreedy at udel.edu  Tue May  6 21:00:57 2014
From: tjreedy at udel.edu (Terry Reedy)
Date: Tue, 06 May 2014 15:00:57 -0400
Subject: [Idle-dev] Fwd: Idle working on OS 10.9.2?
In-Reply-To: <76CC1763-0970-40FA-8A53-50D79E659C41@birdlandobservatory.net>
References: <6DD8080F-F2D0-4B3E-B979-645DFF679457@birdlandobservatory.net>
 <76CC1763-0970-40FA-8A53-50D79E659C41@birdlandobservatory.net>
Message-ID: <lkbbhd$gkp$3@ger.gmane.org>

On 3/29/2014 5:48 PM, birdlandbill wrote:

>> Just wondering if anyone has been able to run Idle 2.7.6 on OS 10.9.2

I expect so. There may have been an issue on the tracker. One of the 
answers is to use the proper version of tck/tk for the OS and Python 
version.

-- 
Terry Jan Reedy


From nad at acm.org  Tue May  6 21:15:26 2014
From: nad at acm.org (Ned Deily)
Date: Tue, 06 May 2014 12:15:26 -0700
Subject: [Idle-dev] Fwd: Idle working on OS 10.9.2?
References: <6DD8080F-F2D0-4B3E-B979-645DFF679457@birdlandobservatory.net>
 <76CC1763-0970-40FA-8A53-50D79E659C41@birdlandobservatory.net>
Message-ID: <nad-E2C5EE.12152606052014@news.gmane.org>

In article 
<76CC1763-0970-40FA-8A53-50D79E659C41 at birdlandobservatory.net>,
 birdlandbill <billperkins at birdlandobservatory.net> wrote:
> Begin forwarded message:
> > From: birdlandbill <billperkins at birdlandobservatory.net>
> > Subject: Idle working on OS 10.9.2?
> > Date: March 29, 2014 at 4:38:28 PM CDT
> > To: idle-dev at python.ord
> > 
> > It isn't on my computer. Worked on 10.8.5, but haven't been successful in 
> > getting Idle 2.7.6 working on two different Macs with 10.9.2. Can start 
> > python 2.7.6 in terminal window by typing python from the home directory. 
> > Entering idle at the home directory results in
> > 
> > python version 2.7.6 can't run /usr/bin/idle. Try the alternative(s):
> > /usr/bin/idle2.7 (uses python 2.7)
> > 
> > /usr/bin/idle2.7 exists in /usr/bin as does /usr/bin/idle
> > 
> > Idle 2.7.6 exists in the Applications folder, but does not execute when 
> > selected.
> > 
> > As an experiment, I downloaded Python 3.4. I can launch it from the version 
> > appropriate Idle file in the Applications folder. I was able to do this 
> > with Idle 2.7.6 in OS 10.8.5.
> > 
> > Just wondering if anyone has been able to run Idle 2.7.6 on OS 10.9.2 and, 
> > if not, how that might be accomplished.

Considering that this post just appeared (lost in transit?), I hope 
you've solved the problem by now but, if not, it is certainly possible 
to run IDLE on OS X 10.9.2 from the Python 2.7.6 installers provided by 
python.org.  Make sure you follow the instructions to also install an 
up-to-date ActiveTcl 8.5.15, if possible.

-- 
 Ned Deily,
 nad at acm.org


From tjreedy at udel.edu  Tue May  6 20:57:32 2014
From: tjreedy at udel.edu (Terry Reedy)
Date: Tue, 06 May 2014 14:57:32 -0400
Subject: [Idle-dev] GSOC 2014
In-Reply-To: <CAMTAJMEU=vN0hi8ByWAEPWDKJz6OcyVqtpSUNc_oELbHxNTzJg@mail.gmail.com>
References: <CAMTAJMEU=vN0hi8ByWAEPWDKJz6OcyVqtpSUNc_oELbHxNTzJg@mail.gmail.com>
Message-ID: <lkbbb0$gkp$1@ger.gmane.org>

On 1/26/2014 2:56 PM, Asish Panda wrote:

This apparently got stuck in the moderation queue, and while this is 
obsolete in respect to GSOC 2014 selection, I will give answers where 
relevant.

> My first question is whether the project list of 2013 is still
> applicable for gsoc 2014.

Not as written. The lists were updated after this was sent. The 2014 
lists will not be applicable for 2015 until updated next January.

> Secondly is it necessary to send a patch related to IDLE that is only
> listed in issue tracker? For example if I want to display line number in
> Editor Window in the left side (similar to gedit in Ubuntu) but it is
> not considered an issue in the issue tracker. Will it be considered a
> legit patch, if I send a patch implementing the line numbers?

1. Without an issue, there is no proper place to send a patch.
2. I believe there was an issue for this, but I cannot find it. Search 
is partly broken.
3. One can create new issues, or ask about creating a new issue.

> My third question is, can I again send a patch for a bug that already
> has been resolved?

This is generally not useful.

-- 
Terry Jan Reedy


From tjreedy at udel.edu  Tue May  6 20:58:56 2014
From: tjreedy at udel.edu (Terry Reedy)
Date: Tue, 06 May 2014 14:58:56 -0400
Subject: [Idle-dev] Non-buildbot human mediated tests
In-Reply-To: <CAO3PiBjvqSkBKXytLByg35H9-aHSMjT6i29Vw9cyssvhPhpECA@mail.gmail.com>
References: <CAO3PiBjvqSkBKXytLByg35H9-aHSMjT6i29Vw9cyssvhPhpECA@mail.gmail.com>
Message-ID: <lkbbdk$gkp$2@ger.gmane.org>

On 4/27/2014 1:34 AM, Saimadhav Heblikar wrote:
> Hi,
> In this email, I'd like to detail how i plan to move forward on making
> human mediated non-buildbot tests in IDLE.

I answered this privately while it was stuck in the queue. Saimadhav is 
preparing a new version to post.

-- 
Terry Jan Reedy


From nad at acm.org  Tue May  6 21:10:46 2014
From: nad at acm.org (Ned Deily)
Date: Tue, 06 May 2014 12:10:46 -0700
Subject: [Idle-dev] Non-buildbot human mediated tests
References: <CAO3PiBjvqSkBKXytLByg35H9-aHSMjT6i29Vw9cyssvhPhpECA@mail.gmail.com>
Message-ID: <nad-26FC15.12104606052014@news.gmane.org>

In article 
<CAO3PiBjvqSkBKXytLByg35H9-aHSMjT6i29Vw9cyssvhPhpECA at mail.gmail.com>,
 Saimadhav Heblikar <saimadhavheblikar at gmail.com> wrote:
> Have i missed any other aspect?

A metapoint about IDLE: it is crucial to keep in mind that IDLE is both 
a Python application and a Tk application.  In many ways, the latter is 
more significant than the former because, unfortunately but unavoidably, 
there are many more significant platform-dependent differences (e.g. 
Windows native vs X11 vs OS X native) in Tk apps than there are in 
Python apps.  That's primarily because Tk tries to adopt 
platform-specific behaviors and appearances to blend in with the GUI 
standards of the platform it is running on.  One simple example: on OS 
X, the standard is for there to be one application-specific menu bar 
presented at the top of the desktop screen; with Windows and X11 apps, 
the standard is to have a menu bar at the top of application windows.  
This has impact on IDLE's appearance to users: on Windows, if you have 
both a shell and an edit window open, each has its own customized menu 
bar with both visible, whereas on OS X, the single menu bar at the top 
shows only the menu options for the window which currently has input 
focus.  Another example is that the menu accelerator keyboard shortcuts 
vary from platform-to-platform due to both platform conventions and, in 
some cases, due to shortcomings in the Tk implementations.  A special 
case is the OS X Cocoa Tk implementation, the newest and the buggiest of 
the Tk implementations.  The versions shipped so far with OS X releases 
have proven to have enough serious problems that we strongly recommend 
users to not try to use them but use a newer, third-party version (like 
ActiveTcl) instead.

Because of all these differences, I don't think it is meaningful to talk 
about GUI tests of IDLE without a thorough consideration of the Tk 
aspects.  To be effective, any testing program will need to plan to test 
in all three of the major environments we currently support, taking into 
account their differences.  It also might be interesting to find out how 
the Tk project tests Tk and other Tk apps; perhaps something could be 
reused from there.

Good luck with the project!

-- 
 Ned Deily,
 nad at acm.org


From tjreedy at udel.edu  Wed May  7 04:47:24 2014
From: tjreedy at udel.edu (Terry Reedy)
Date: Tue, 06 May 2014 22:47:24 -0400
Subject: [Idle-dev] Non-buildbot human mediated tests
In-Reply-To: <nad-26FC15.12104606052014@news.gmane.org>
References: <CAO3PiBjvqSkBKXytLByg35H9-aHSMjT6i29Vw9cyssvhPhpECA@mail.gmail.com>
 <nad-26FC15.12104606052014@news.gmane.org>
Message-ID: <lkc6s0$isq$1@ger.gmane.org>

On 5/6/2014 3:10 PM, Ned Deily wrote:
> In article
> <CAO3PiBjvqSkBKXytLByg35H9-aHSMjT6i29Vw9cyssvhPhpECA at mail.gmail.com>,
>   Saimadhav Heblikar <saimadhavheblikar at gmail.com> wrote:
>> Have i missed any other aspect?
>
> A metapoint about IDLE: it is crucial to keep in mind that IDLE is both
> a Python application and a Tk application.  In many ways, the latter is
> more significant than the former because, unfortunately but unavoidably,
> there are many more significant platform-dependent differences (e.g.
> Windows native vs X11 vs OS X native) in Tk apps than there are in
> Python apps.  That's primarily because Tk tries to adopt
> platform-specific behaviors and appearances to blend in with the GUI
> standards of the platform it is running on.

 > One simple example: on OS
> X, the standard is for there to be one application-specific menu bar
> presented at the top of the desktop screen; with Windows and X11 apps,
> the standard is to have a menu bar at the top of application windows.
> This has impact on IDLE's appearance to users: on Windows, if you have
> both a shell and an edit window open, each has its own customized menu
> bar with both visible, whereas on OS X, the single menu bar at the top
> shows only the menu options for the window which currently has input
> focus.

Interesting. My dream is to have side-by-side panes in one window. This 
would mean that the one menu bar would have a change a bit according to 
the pane with focus. (If shell and editors were on different tabs in one 
window, the effect would be the same.)

 > Another example is that the menu accelerator keyboard shortcuts
> vary from platform-to-platform due to both platform conventions and, in
> some cases, due to shortcomings in the Tk implementations.  A special
> case is the OS X Cocoa Tk implementation, the newest and the buggiest of
> the Tk implementations.  The versions shipped so far with OS X releases
> have proven to have enough serious problems that we strongly recommend
> users to not try to use them but use a newer, third-party version (like
> ActiveTcl) instead.

Do the OS X peculiarities affect anything other than the menu bar? Do 
pop-up dialogs, such 'about' or 'preferences' look significantly different>

> Because of all these differences, I don't think it is meaningful to talk
> about GUI tests of IDLE without a thorough consideration of the Tk
> aspects.

There are two types of GUI 'tests'. The automated tests run on the 
buildbots. Automated Gui tests run on Windows buildbots, one OS buildbot 
I believe, and maybe one *nix bot, though mostly not on on the others.

Human gui tests
http://bugs.python.org/issue18104
are about visual appearance and response to human input. There are 20+ 
at the end of various files. But they are seldom run because a) they are 
scattered and b) many do not run properly. Issue 18104 is about fixing 
and collecting the tests involve humans. Parts that can be automated 
will be, though some redundancy is good since the Gui part of the 
automated tests are not run everywhere. These tests will have at most 
one window with a menu on the screen at any one time.

> To be effective, any testing program will need to plan to test
> in all three of the major environments we currently support, taking into
> account their differences.

Definitedly. I would be happy if you tested htest4 before I apply a 
version of it the next few days. (It needs to be in place before May 19 
so Saimadhav can start adding to it.) Once htest.py is somewhat 
complete, I would like various people to run it on various systems.

> It also might be interesting to find out how
> the Tk project tests Tk and other Tk apps; perhaps something could be
> reused from there.

While I do not want to duplicate tests of tkinter, I plan on looking at 
if and how tkinter tests automate user interaction.

-- 
Terry Jan Reedy


From saimadhavheblikar at gmail.com  Thu May  8 15:08:09 2014
From: saimadhavheblikar at gmail.com (Saimadhav Heblikar)
Date: Thu, 8 May 2014 18:38:09 +0530
Subject: [Idle-dev] Non-buildbot human mediated tests
In-Reply-To: <lkc6s0$isq$1@ger.gmane.org>
References: <CAO3PiBjvqSkBKXytLByg35H9-aHSMjT6i29Vw9cyssvhPhpECA@mail.gmail.com>
 <nad-26FC15.12104606052014@news.gmane.org> <lkc6s0$isq$1@ger.gmane.org>
Message-ID: <CAO3PiBjBZQWYNeqEkac9G+xNmUSGZNRGEw+bZx58P_GMtzEJrw@mail.gmail.com>

Ned Deily wrote:
>> One simple example: on OS X ..
Thanks for this suggestion. I was unaware of differences in OSX
platform. I will keep this in mind when creating the human tests and
in future development.

>> I don't think it is meaningful to talk about GUI tests of IDLE without a thorough consideration of the Tk aspects.

As Terry Reedy mentions in his reply, these tests "test" whether
visual aspects appear as intended i.e. they provide a sanity check on
all the dialog windows.

>>It also might be interesting to find out howthe Tk project tests Tk and other Tk apps; perhaps something could be reused from there.

I will do this immediately. I will find out if/how it is automated.

-------------------------------

With respect to testing on different platforms, i currently have
access to Linux, a mac osx(10.5.8, which i expect to upgrade soon),
and a winxp.
If someone wants to help test on a specific os/platform, please let me know.

------------------------------
(From my initial post).

I will provide a quick summary of discussion over the past week.

>>We can also ask the tester to choose one of {Pass,Error etc}, which will also be printed to console.
In case there is an exception, it will be printed to console. The
tester will NOT be asked to pick one of {pass,fail/error} to avoid
complication.

>>1. How to pass information to htest?
All the information required to run the tests will be placed in a
single file, instead of being scattered across files - because 1. all
tests can be run together(if and when required) 2. consistency 3.
provides a clear picture of whats covered and whats not

>>possibility of ALL these tests being run together?
There should be a possibility to run all the tests together. While
automation would be good, in the worst case, a simple "click next"
should be present to iterate through all the tests. Result to be
displayed in a way similar to current unittests and with stats.

------------------------------

Saimadhav Heblikar




On 7 May 2014 08:17, Terry Reedy <tjreedy at udel.edu> wrote:
> On 5/6/2014 3:10 PM, Ned Deily wrote:
>>
>> In article
>> <CAO3PiBjvqSkBKXytLByg35H9-aHSMjT6i29Vw9cyssvhPhpECA at mail.gmail.com>,
>>   Saimadhav Heblikar <saimadhavheblikar at gmail.com> wrote:
>>>
>>> Have i missed any other aspect?
>>
>>
>> A metapoint about IDLE: it is crucial to keep in mind that IDLE is both
>> a Python application and a Tk application.  In many ways, the latter is
>> more significant than the former because, unfortunately but unavoidably,
>> there are many more significant platform-dependent differences (e.g.
>> Windows native vs X11 vs OS X native) in Tk apps than there are in
>> Python apps.  That's primarily because Tk tries to adopt
>> platform-specific behaviors and appearances to blend in with the GUI
>> standards of the platform it is running on.
>
>
>> One simple example: on OS
>>
>> X, the standard is for there to be one application-specific menu bar
>> presented at the top of the desktop screen; with Windows and X11 apps,
>> the standard is to have a menu bar at the top of application windows.
>> This has impact on IDLE's appearance to users: on Windows, if you have
>> both a shell and an edit window open, each has its own customized menu
>> bar with both visible, whereas on OS X, the single menu bar at the top
>> shows only the menu options for the window which currently has input
>> focus.
>
>
> Interesting. My dream is to have side-by-side panes in one window. This
> would mean that the one menu bar would have a change a bit according to the
> pane with focus. (If shell and editors were on different tabs in one window,
> the effect would be the same.)
>
>
>> Another example is that the menu accelerator keyboard shortcuts
>>
>> vary from platform-to-platform due to both platform conventions and, in
>> some cases, due to shortcomings in the Tk implementations.  A special
>> case is the OS X Cocoa Tk implementation, the newest and the buggiest of
>> the Tk implementations.  The versions shipped so far with OS X releases
>> have proven to have enough serious problems that we strongly recommend
>> users to not try to use them but use a newer, third-party version (like
>> ActiveTcl) instead.
>
>
> Do the OS X peculiarities affect anything other than the menu bar? Do pop-up
> dialogs, such 'about' or 'preferences' look significantly different>
>
>
>> Because of all these differences, I don't think it is meaningful to talk
>> about GUI tests of IDLE without a thorough consideration of the Tk
>> aspects.
>
>
> There are two types of GUI 'tests'. The automated tests run on the
> buildbots. Automated Gui tests run on Windows buildbots, one OS buildbot I
> believe, and maybe one *nix bot, though mostly not on on the others.
>
> Human gui tests
> http://bugs.python.org/issue18104
> are about visual appearance and response to human input. There are 20+ at
> the end of various files. But they are seldom run because a) they are
> scattered and b) many do not run properly. Issue 18104 is about fixing and
> collecting the tests involve humans. Parts that can be automated will be,
> though some redundancy is good since the Gui part of the automated tests are
> not run everywhere. These tests will have at most one window with a menu on
> the screen at any one time.
>
>
>> To be effective, any testing program will need to plan to test
>> in all three of the major environments we currently support, taking into
>> account their differences.
>
>
> Definitedly. I would be happy if you tested htest4 before I apply a version
> of it the next few days. (It needs to be in place before May 19 so Saimadhav
> can start adding to it.) Once htest.py is somewhat complete, I would like
> various people to run it on various systems.
>
>
>> It also might be interesting to find out how
>> the Tk project tests Tk and other Tk apps; perhaps something could be
>> reused from there.
>
>
> While I do not want to duplicate tests of tkinter, I plan on looking at if
> and how tkinter tests automate user interaction.
>
> --
> Terry Jan Reedy
>
>
> _______________________________________________
> IDLE-dev mailing list
> IDLE-dev at python.org
> https://mail.python.org/mailman/listinfo/idle-dev

From saimadhavheblikar at gmail.com  Thu May 15 18:26:15 2014
From: saimadhavheblikar at gmail.com (Saimadhav Heblikar)
Date: Thu, 15 May 2014 21:56:15 +0530
Subject: [Idle-dev] Non-buildbot human mediated tests
In-Reply-To: <CAO3PiBjBZQWYNeqEkac9G+xNmUSGZNRGEw+bZx58P_GMtzEJrw@mail.gmail.com>
References: <CAO3PiBjvqSkBKXytLByg35H9-aHSMjT6i29Vw9cyssvhPhpECA@mail.gmail.com>
 <nad-26FC15.12104606052014@news.gmane.org> <lkc6s0$isq$1@ger.gmane.org>
 <CAO3PiBjBZQWYNeqEkac9G+xNmUSGZNRGEw+bZx58P_GMtzEJrw@mail.gmail.com>
Message-ID: <CAO3PiBiXr-VXp8F=B-hg9cr+yxiR5jreTORS_UFCOCVDzspCJw@mail.gmail.com>

Hi,
I was going through the htest.py commit.

1.
The line klas_kwds['parent'] = root (line 69) and the related comment
" # This presumes that Idle consistently uses 'parent'", could cause
certain problems with widgets not directly requiring a 'parent'
argument.(From my recall, these include PathBrowser and ClassBrowser).

One way to solve would be to move root to a namespace one level higher
and include the 'parent' arg as any you would include any other arg.
We will also get a Tk() object in the same namespace as the spec
dicts.(For eg - Useful in context of ClassBrowser which requires root
to create a PyshellFileList) This will make certain aspects easier and
more readable. This approach worked when I tested it against
ClassBrowser and the existing aboutDialog.

Another way is to include metadata in "<classname>_spec" dict to
indicate whether 'parent' is needed or not. This i feel is clumsy and
could make code in run() spaghetti.
I personally prefer the first way.


Regards
Saimadhav Heblikar

From tjreedy at udel.edu  Fri May 16 02:53:09 2014
From: tjreedy at udel.edu (Terry Reedy)
Date: Thu, 15 May 2014 20:53:09 -0400
Subject: [Idle-dev] Non-buildbot human mediated tests
In-Reply-To: <CAO3PiBiXr-VXp8F=B-hg9cr+yxiR5jreTORS_UFCOCVDzspCJw@mail.gmail.com>
References: <CAO3PiBjvqSkBKXytLByg35H9-aHSMjT6i29Vw9cyssvhPhpECA@mail.gmail.com>
 <nad-26FC15.12104606052014@news.gmane.org> <lkc6s0$isq$1@ger.gmane.org>
 <CAO3PiBjBZQWYNeqEkac9G+xNmUSGZNRGEw+bZx58P_GMtzEJrw@mail.gmail.com>
 <CAO3PiBiXr-VXp8F=B-hg9cr+yxiR5jreTORS_UFCOCVDzspCJw@mail.gmail.com>
Message-ID: <ll3nht$m87$1@ger.gmane.org>

On 5/15/2014 12:26 PM, Saimadhav Heblikar wrote:
> I was going through the htest.py commit.

Code comments should go in a Rietveld code review or a tracker message. 
Questions like the below on the tracker are ok, even if the issue 
(18104) is 'closed'. After a commit, there can also be a response to the 
commit message on the python-checkins list (though one may need to be a 
committer to post). In all three cases, the context is available.

> The line klas_kwds['parent'] = root (line 69) and the related comment
> " # This presumes that Idle consistently uses 'parent'", could cause
> certain problems with widgets not directly requiring a 'parent'

The comment is obsolete; it was written when I was thinking only in 
terms of calling a widget class. I soon discovered that sometimes a 
wrapper function is needed (as in 2 of the 4 cases I tried and 
included). A corrected comment was already included in the module 
docstring. I just pushed a patch removing both obsolete comments and 
revising the docstrings

-- 
Terry Jan Reedy


From saimadhavheblikar at gmail.com  Mon May 19 04:21:54 2014
From: saimadhavheblikar at gmail.com (Saimadhav Heblikar)
Date: Mon, 19 May 2014 07:51:54 +0530
Subject: [Idle-dev] Non-buildbot human mediated tests
In-Reply-To: <ll3nht$m87$1@ger.gmane.org>
References: <CAO3PiBjvqSkBKXytLByg35H9-aHSMjT6i29Vw9cyssvhPhpECA@mail.gmail.com>
 <nad-26FC15.12104606052014@news.gmane.org> <lkc6s0$isq$1@ger.gmane.org>
 <CAO3PiBjBZQWYNeqEkac9G+xNmUSGZNRGEw+bZx58P_GMtzEJrw@mail.gmail.com>
 <CAO3PiBiXr-VXp8F=B-hg9cr+yxiR5jreTORS_UFCOCVDzspCJw@mail.gmail.com>
 <ll3nht$m87$1@ger.gmane.org>
Message-ID: <CAO3PiBjdYrS_2daKUuU568y-5q_mVQg_nyUZu_1WdAzjiXyJNw@mail.gmail.com>

* Improving run() and runall()

I propose slight modification in the way run() and runall() are structured.
run() and runall() could be refactored into a single utility
function(called run())

This function will have an optional parameter. If the function is
being called from another module, then the parameter has to be present
in the call to ensure only the assocated test is run.

If the optional parameter is not present(the case when htest.py is
run,-from if __name__=='__main__' part), then all the tests have to be
run.

Either way, a test_list will will store the *names*(as str's) of
wrapper functions/ callable objects , which when processed by a
utility function, will start a particular test. "_spec" appended to
the name string will give the spec dict.

The same root object will be used irrespective of the number of tests.
Test_list will be popped as soon as the user clicks "next"/ finishes a
test. Once all the tests are done, popping again will raise an index
error signalling the end.
Updating information like current callable object, keywords,
information string etc will be done when the user clicks
"next"/finishes a test.

As far as actual runner code, a button will be used to begin *a*
particular test/as soon as a test gets over.
Based on the name string, the module will be imported and run.(in the
same way as currently present in runall().)



On 16 May 2014 06:23, Terry Reedy <tjreedy at udel.edu> wrote:
> On 5/15/2014 12:26 PM, Saimadhav Heblikar wrote:
>>
>> I was going through the htest.py commit.
>
>
> Code comments should go in a Rietveld code review or a tracker message.
> Questions like the below on the tracker are ok, even if the issue (18104) is
> 'closed'. After a commit, there can also be a response to the commit message
> on the python-checkins list (though one may need to be a committer to post).
> In all three cases, the context is available.
>
>
>> The line klas_kwds['parent'] = root (line 69) and the related comment
>> " # This presumes that Idle consistently uses 'parent'", could cause
>> certain problems with widgets not directly requiring a 'parent'
>
>
> The comment is obsolete; it was written when I was thinking only in terms of
> calling a widget class. I soon discovered that sometimes a wrapper function
> is needed (as in 2 of the 4 cases I tried and included). A corrected comment
> was already included in the module docstring. I just pushed a patch removing
> both obsolete comments and revising the docstrings
>
>
> --
> Terry Jan Reedy
>
> _______________________________________________
> IDLE-dev mailing list
> IDLE-dev at python.org
> https://mail.python.org/mailman/listinfo/idle-dev