From taleinat at gmail.com  Thu Apr 10 10:18:17 2014
From: taleinat at gmail.com (Tal Einat)
Date: Thu, 10 Apr 2014 11:18:17 +0300
Subject: [Idle-dev] [Python-Dev] A Friendly IDLE
In-Reply-To: <li4erp$6e0$1@ger.gmane.org>
References: <5344cec2.6152c20a.0bb9.ffffce81@mx.google.com>
 <li4erp$6e0$1@ger.gmane.org>
Message-ID: <CALWZvp4eY2bWyS1DDa1TcF_UL4MWCG0+3vPCSjzdjohaDdVjZQ@mail.gmail.com>

On Thu, Apr 10, 2014 at 12:42 AM, Terry Reedy <tjreedy at udel.edu> wrote:
> On 4/9/2014 12:25 AM, adnanumer95 at gmail.com wrote:

> Python-list, python-ideas, or idle-dev lists might have been better places to put this, but here are my responses.

I'm adding idle-dev, where this belongs. Further discussion should
take place there rather than on python-dev.

>>  3.
>>     In Python Shell Save & Save As menus are enable and using them we
>>     can save shell text as python script (.py) that never executes again
>>     on IDLE. I recommends to either disable this option or save shell
>>     text as plain text. I made a little try to disable this and succeed.
>
>
> We will not disable being able to save the shell window.
> http://bugs.python.org/issue11838 is about saving in runnable form.

If IDLE saves the shell history to a file with a .py extension by
default, that is indeed confusing. It is useful to be able to save the
history to a file, but it shouldn't have a .py extension.

- Tal Einat

From tjreedy at udel.edu  Thu Apr 10 13:15:32 2014
From: tjreedy at udel.edu (Terry Reedy)
Date: Thu, 10 Apr 2014 07:15:32 -0400
Subject: [Idle-dev] [Python-Dev] A Friendly IDLE
In-Reply-To: <CALWZvp4eY2bWyS1DDa1TcF_UL4MWCG0+3vPCSjzdjohaDdVjZQ@mail.gmail.com>
References: <5344cec2.6152c20a.0bb9.ffffce81@mx.google.com>
 <li4erp$6e0$1@ger.gmane.org>
 <CALWZvp4eY2bWyS1DDa1TcF_UL4MWCG0+3vPCSjzdjohaDdVjZQ@mail.gmail.com>
Message-ID: <li5uh2$os1$1@ger.gmane.org>

On 4/10/2014 4:18 AM, Tal Einat wrote:
> On Thu, Apr 10, 2014 at 12:42 AM, Terry Reedy <tjreedy at udel.edu> wrote:
>> On 4/9/2014 12:25 AM, adnanumer95 at gmail.com wrote:

>>>      In Python Shell Save & Save As menus are enable and using them we
>>>      can save shell text as python script (.py) that never executes again
>>>      on IDLE. I recommends to either disable this option or save shell
>>>      text as plain text. I made a little try to disable this and succeed.
>>
>> We will not disable being able to save the shell window.
>> http://bugs.python.org/issue11838 is about saving in runnable form.
>
> If IDLE saves the shell history to a file with a .py extension by
> default, that is indeed confusing. It is useful to be able to save the
> history to a file, but it shouldn't have a .py extension.

I agree: if shell window is saved as is, as logfile, as at present, the 
default should be .txt. #21140 is about changing default for Output 
Window; same method will work shell. Issue above is really about adding 
a second save option.

-- 
Terry Jan Reedy


From alan.gauld at btinternet.com  Fri Apr 18 23:35:13 2014
From: alan.gauld at btinternet.com (Alan Gauld)
Date: Fri, 18 Apr 2014 22:35:13 +0100
Subject: [Idle-dev] [Python-Dev] A Friendly IDLE
In-Reply-To: <li5uh2$os1$1@ger.gmane.org>
References: <5344cec2.6152c20a.0bb9.ffffce81@mx.google.com>
 <li4erp$6e0$1@ger.gmane.org>
 <CALWZvp4eY2bWyS1DDa1TcF_UL4MWCG0+3vPCSjzdjohaDdVjZQ@mail.gmail.com>
 <li5uh2$os1$1@ger.gmane.org>
Message-ID: <lis5qh$sjc$1@ger.gmane.org>

On 10/04/14 12:15, Terry Reedy wrote:

> I agree: if shell window is saved as is, as logfile, as at present, the
> default should be .txt. #21140 is about changing default for Output
> Window; same method will work shell. Issue above is really about adding
> a second save option.

A long long time ago I used to use the VAX VMS debugger and one
of its greatest features was that you could save an interactive
session (as text) and then rerun it. the interpreter was smart
enough to ignore the DBG> prompts and the output lines(I think
they had a prefix too???).

This made long debugging sessions  easy to save and resume by
just rerunning the old session - which typically could take
maybe 2 minutes to rerun an entire 4 hour debug session.
You could also build test scripts very easily by running
a debug session then editing out (or copying and modifying)
the bits you didn't need (or needed).

Now, if Python (or any other IDE) could do that it would
be fantastic, Especially when working with Tkinter where
you often lose the object references when a program run ends
and have to restart from scratch each time. To rerun the
whole session up to some point would be great.

I've no idea what it would take to tweak the IDLE
interpreter/front-end to achieve that but I'd love if it
were so.

-- 
Alan G
Author of the Learn to Program web site
http://www.alan-g.me.uk/
http://www.flickr.com/photos/alangauldphotos


From saimadhavheblikar at gmail.com  Sun Apr 27 07:34:57 2014
From: saimadhavheblikar at gmail.com (Saimadhav Heblikar)
Date: Sun, 27 Apr 2014 11:04:57 +0530
Subject: [Idle-dev] Non-buildbot human mediated tests
Message-ID: <CAO3PiBjvqSkBKXytLByg35H9-aHSMjT6i29Vw9cyssvhPhpECA@mail.gmail.com>

Hi,
In this email, I'd like to detail how i plan to move forward on making
human mediated non-buildbot tests in IDLE.

Existing discussions - http://bugs.python.org/issue18104

A file called htest.py to be present in idlelib/idle_test. This file
will have a root gui. This gui will contain information about the
module. It will contain information useful to the tester - what
aspects to test, what are the results to be expected etc. Formatting
this is trivial. It will have a button to start the test(run the
module in hand).

Once the testing is over, we see if any exception was raised. If yes,
print the same to console and fail the test. We can also ask the
tester to choose one of {Pass,Error etc}, which will also be printed
to console.

Moving to the design aspect,

1. How to pass information to htest?
By information, i am referring to "help information string" for
tester, arguments to be passed to htest etc. This information can be
stored in a dict.
There are two possibilities -
 a) store the information related to each module in the module itself.
The advantages are obvious to see  - Its better organized and will
also give the developer an idea about the module
b) store all the information per module in htest.py . I don't feel
this option would help, but mentioning here to see if there are any
advantages of going this way.

2. Should I consider the possibility of ALL these tests being run together?
(Much the same way as unitttests are run now - like "python -m
unittest -v idlelib.idle_test").

In this case, i plan to keep it simple. Just display the dialog's as
if they are being run individually,(one after another), and print the
result to console.
This can done using a simple loop.

Have i missed any other aspect?

I am awaiting your feedback.

Regards
Saimadhav Heblikar
GSoC 2014 Student
Overview : http://blog.saimadhav.com/2014/04/gsoc-2014-workflow-resources.html


NS: I have made a rough overview of which modules need gui testing,
whether they are indirectly being tested etc. at
http://bit.ly/1k5JmHn. Feel free to comment.