From dscherer at cmu.edu  Fri Jun  3 02:16:05 2005
From: dscherer at cmu.edu (dscherer@cmu.edu)
Date: Fri, 3 Jun 2005 08:16:05 +0800
Subject: [Idle-dev] hello
Message-ID: <200506030009.j5309Tej010724@skyzonetours.com>

------------------  Virus Warning Message (on mail2.skyzonetours.com)

Found virus WORM_MYTOB.BW in file document.txt                                                                      .pif (in document.zip)
The uncleanable file is deleted.

---------------------------------------------------------
-------------- next part --------------
The message contains Unicode characters and has been sent as a binary attachment.

-------------- next part --------------

------------------  Virus Warning Message (on mail2.skyzonetours.com)

document.zip is removed from here because it contains a virus.

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

From alin.moldoveanu at rdslink.ro  Sun Jun  5 21:09:48 2005
From: alin.moldoveanu at rdslink.ro (Alin Moldoveanu)
Date: Sun, 5 Jun 2005 22:09:48 +0300
Subject: [Idle-dev] IDLE command line options
Message-ID: <000e01c56a02$24c92cd0$88654e52@bebe>

Where can I find the complete list of command line options for the IDLE editor ?!

I need it to be able to open a Python file at a certain line (more precisely where a certain function is located - but this can be found by parsing the file).

Thanks for the help.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.python.org/pipermail/idle-dev/attachments/20050605/e321368f/attachment.htm

From kbk at shore.net  Mon Jun  6 20:22:47 2005
From: kbk at shore.net (Kurt B. Kaiser)
Date: Mon, 06 Jun 2005 14:22:47 -0400
Subject: [Idle-dev] IDLE command line options
In-Reply-To: <000e01c56a02$24c92cd0$88654e52@bebe> (Alin Moldoveanu's
	message of "Sun, 5 Jun 2005 22:09:48 +0300")
References: <000e01c56a02$24c92cd0$88654e52@bebe>
Message-ID: <877jh7wdjc.fsf@hydra.bayview.thirdcreek.com>

"Alin Moldoveanu" <alin.moldoveanu at rdslink.ro> writes:

> Where can I find the complete list of command line options for the
> IDLE editor ?!

At the end of Help / IDLE Help there are instructions for this.

(answer: enter idle -h at the command prompt)

>
> I need it to be able to open a Python file at a certain line (more
> precisely where a certain function is located - but this can be
> found by parsing the file).


-- 
KBK

From kbk at shore.net  Mon Jun  6 20:26:42 2005
From: kbk at shore.net (Kurt B. Kaiser)
Date: Mon, 06 Jun 2005 14:26:42 -0400
Subject: [Idle-dev] debugging with idle
In-Reply-To: <9782D6A4D5C1E04EA1465591C323EB1B1DC07B@studentex6.campus.tue.nl>
	(C. L. L. Bartels's message of "Mon, 23 May 2005 11:49:05 +0200")
References: <9782D6A4D5C1E04EA1465591C323EB1B1DC07B@studentex6.campus.tue.nl>
Message-ID: <873brvwdct.fsf@hydra.bayview.thirdcreek.com>

"Bartels, C.L.L." <C.L.L.Bartels at student.tue.nl> writes:

> I've been using idle for some time now, and I really like it, it is
> small/clean/comes with the standard python package and can do most of
> what I want. Only it's debugging capability is a bit incomplete (or I
> am not using it correctly, so correct me if I am wrong), i.e. I use a
> lot of classes with submembers (which for example are lists with
> implicit references to other python objects) etc... And I can't really
> view them in the python debugger, it only sais: "class instance at
> addr xxx" and I cant click it or view deeper into it. Any ideas on
> this?

Yes, it would be nice if the debugger grew a way to interactively
examine objects in a given frame.  Someday.

Until then, print is your friend.

-- 
KBK

From kbk at shore.net  Mon Jun  6 20:33:23 2005
From: kbk at shore.net (Kurt B. Kaiser)
Date: Mon, 06 Jun 2005 14:33:23 -0400
Subject: [Idle-dev] module won't run in IDLE: puzzling traceback
References: <427E5E17.80608@po-box.mcgill.ca>
Message-ID: <87u0kbuyh8.fsf@hydra.bayview.thirdcreek.com>

Brian van den Broek <bvande at po-box.mcgill.ca> writes:

> I'm a hobbyist who posts mostly to Tutor; I'm doing my level best to 
> handle this "right". Apologies for any mis-steps. I have googled the 
> web and searched the gmane archive of this list for the terms 
> asyncqueue and putmessage but did not come up with anything that I 
> recognized as relevant.

Thanks!  You're definitely on the right track!

> The problem:
>
> I have a module which, when I run it with IDLE 1.1.1 produces the 
> following traceback:
>
> IDLE 1.1.1
>  >>> ================================ RESTART 
> ================================
>  >>>
> Traceback (most recent call last):
>    File "C:\PYTHON24\lib\idlelib\rpc.py", line 233, in asyncqueue
>      self.putmessage((seq, request))
>    File "C:\PYTHON24\lib\idlelib\rpc.py", line 333, in putmessage
>      raise IOError
> IOError

There was a socket error, or the socket no longer exists.  In other
words, the link to the subprocess failed while the IDLE GUI was trying
to pass the compiled code to the subprocess for execution.

> It leaves the program running (attempts to close the shell window 
> produce a "The program is still running!" dialog). My environment is 
> Python 2.4.1 running on a WindowsME box. Possibly of relevance: 1) I 
> run ZoneAlarm, 

Since this is fairly reproducible, try disconnecting from the web
for safety's sake, turn off ZoneAlarm, and see if the problem 
remains.  I suspect it will, but let's check.

> and 2) I often, but unpredictably, get the IDLE subprocess error
> message when attempting to relaunch IDLE after having shut it down,
> and have to kill a running Pythonw process in TaskManager to
> relaunch.

Windows, especially Windows ME, doesn't seem to always handle sockets
correctly when the GUI end of the socket goes away.  The subprocess
end should sense this, and that would cause IDLE's subprocess to exit.
If that doesn't happen, then when IDLE is started a conflict occurs.

I'm looking into adding "belt and suspenders" by sending an explicit
exit message to the subprocess before closing the socket from the
GUI end.

> My module runs fine when run via each of the following: a DOS
> console Python interpreter, PythonWin, DrPython, and SciTE. (When
> applicable, the each tool's 'Check Syntax' command passes just fine,
> and this includes the check in IDLE itself.)
>
> I have encountered this before with other modules of mine. I generally 
> use Leo (a pure Python literate programming outline style code editor 
> <http://webpages.charter.net/edreamleo/front.html>) to edit my longer 
> pieces of code. In the present case, and I believe in previous cases 
> of the same problem, I did indeed use Leo to write my code. Thus, I 
> cannot rule out that Leo is somehow implicated or at fault, but the 
> fact that other means of running my module work make me suspect it is 
> an IDLE issue, rather than a Leo one. (Previous cases of this problem 
> when running via IDLE also worked when ran via other means.)
>
> I realize that it would be helpful to have a minimal snippet 
> exhibiting the problem. But, I have been unable so far to produce a 
> small snippet. My original module is over 1200 loc, and I have spent 
> the better part of an hour trying to pare it down; I have reduced it 
> but it still stands at just under 750 loc. I am about to give up on 
> the attempt to pare it down further--at this point, removing any 
> docstrings, classes, methods, if blocks, or even print statements 
> cause the problem to disappear. (Indeed, I was only able to remove a 
> few classes, top-level statements, and all comments while preserving 
> the problem.)
>
> I have checked, and there are no tabs in my module and all lines end 
> with the Unix standard \n rather than the Windows \r\n. (I tried 
> converting to \r\n line endings, and it makes no difference.)
>
> I know nothing of IDLE's internals, and am not sufficiently skilled in 
> programming to acquire a meaningful understanding in a reasonable 
> time-frame. I would very much appreciate suggestions as to how to 
> narrow down the problem further.

I think the only way to get at this is to zip up your original module
and email it to me as an attachment.  I'll try to duplicate the
problem on Windows 2000.

In the meantime, you can run IDLE without the subprocess.
Unfortunately, with the new Windows installer it's no longer possible
to edit the IDLE launcher in the Start menu to use the -n switch.  I
guess I'll have to add an option in IDLE's configuration.

Meanwhile, simply open C:\Python24\Lib\idlelib\PyShell.py and at line
1272 change

use_subprocess = True

to

use_subprocess = False

Save PyShell.py, restart IDLE, and you will see a message in the shell
window that IDLE is now running without the subprocess.  This has
disadvantages (see the Tips section of Help / IDLE Help) but should
work for you until we get a handle on this.  Running w/o the
subprocess makes IDLE act more like the other GUIs you're using.

Alternatively, if you know how to create launchers on the Start menu,
you could create "IDLE NSP" which targets

c:\Python24\pythonw.exe  c:\Python24\Lib\idlelib\PyShell.py -n

-- 
KBK

From alin.moldoveanu at rdslink.ro  Wed Jun  8 10:02:54 2005
From: alin.moldoveanu at rdslink.ro (Alin Moldoveanu)
Date: Wed, 8 Jun 2005 11:02:54 +0300
Subject: [Idle-dev] idle -h etc
Message-ID: <00d601c56c00$79bee2c0$88654e52@bebe>

"idle -h" does not work in my Python installation (2.4 on Windows).

Anyway, I had a look at the source code, there was no option for starting
the editor at a certain line in a file.

But the source code it's quite clear and easy to change to do whatever I
want at startup.

Btw, IDLE has the same "free" license as Python, right ?!

And, regarding debugging facilities in IDLE. I just found the Python
language and I intend to use it in a big project. I think it's a great
language with powerful libraries. In contrast, the debugger for the standard
distributed editor (IDLE) is too simplistic and not even the easies to use.
I think improving IDLE (mostly the debugger) will help a lot many
developers.


From alin.moldoveanu at rdslink.ro  Wed Jun  8 19:36:12 2005
From: alin.moldoveanu at rdslink.ro (Alin Moldoveanu)
Date: Wed, 8 Jun 2005 20:36:12 +0300
Subject: [Idle-dev] Embed question: opening IDLE from another application
Message-ID: <001d01c56c50$90e09cf0$88654e52@bebe>

Here is what I need:
    - from an external program to open a .py file in IDLE and go
automatically to a certain function
    - if the file is already opened in IDLE it shouldn't be reopened, just a
jump to the function is required.
    - the external program can open several files or functions in this way
    - after a file is opened, the application should continue it's normal
execution

Note: Jumping to the function is not an issue, the problem is with starting
IDLE in a correct way.

I tried to open a file in Idle with:
    // the arguments (the name of the file to be opened) are passed using
argc, argv
    PyRun_SimpleString ("import idlelib.PyShell\n");
    yRun_SimpleString ("idlelib.PyShell.main()\n");
    x ...
The problem is:
    - when I start IDLE, the calling code from my application is blocked
until these calls return (only then x is reached). Of course, this is quite
normal.
    - I tried to move these calls on a separate thread. The main thread of
the application doesn't block anymore, but a second call to the 2 methods
above (while the Idle opened by the first call is opened) will cause a crash
in python24.dll.

I'm quite new to Python and I'm sure there should be some simple way to do
what I need.

I hope I didn't bother you with such a long post.
Thanks for any help or suggestion.


From kbk at shore.net  Fri Jun 10 05:11:18 2005
From: kbk at shore.net (Kurt B. Kaiser)
Date: Thu, 09 Jun 2005 23:11:18 -0400
Subject: [Idle-dev] idle -h etc
References: <00d601c56c00$79bee2c0$88654e52@bebe>
Message-ID: <87ll5i3nzd.fsf@hydra.bayview.thirdcreek.com>

"Alin Moldoveanu" <alin.moldoveanu at rdslink.ro> writes:

> "idle -h" does not work in my Python installation (2.4 on Windows).

<open a command window>

cd c:\Python24\Lib\idlelib
idle.py -h

If you just call <idle -h> it is run by pythonw.exe which doesn't
display the command window which receives the output.

> Anyway, I had a look at the source code, there was no option for starting
> the editor at a certain line in a file.

Never claimed there was.

> But the source code it's quite clear and easy to change to do
> whatever I want at startup.

That's what I expected you to do :-)

> Btw, IDLE has the same "free" license as Python, right ?!

Right.  Same license.  Enjoy.

> And, regarding debugging facilities in IDLE. I just found the Python
> language and I intend to use it in a big project. I think it's a
> great language with powerful libraries. In contrast, the debugger for
> the standard distributed editor (IDLE) is too simplistic and not even
> the easies to use.  I think improving IDLE (mostly the debugger) will
> help a lot many developers.

Possibly so.  But if you just discovered Python you may come to feel
that debuggers aren't so useful for 'pure' Python code as they are
for, say, C code.  Print statements work very well and are usually
actually faster than mucking around in the debugger.  The class
browser is also helpful.

The one addition to the debugger I would like is the ability to
execute an arbitrary Python statement in any stack frame at a
breakpoint.  If you really get stuck you can use the Python pdb
debugger (outside of IDLE).  I agree that's not very elegant.

What other capability do you feel is missing?

-- 
KBK

From alin.moldoveanu at rdslink.ro  Fri Jun 10 14:41:35 2005
From: alin.moldoveanu at rdslink.ro (Alin Moldoveanu)
Date: Fri, 10 Jun 2005 15:41:35 +0300
Subject: [Idle-dev] idle -h etc
Message-ID: <003d01c56db9$bccf5990$88654e52@bebe>

What more debugging facilities would I like in Idle:
    1) object browser (to be able to see the fields of an object, in a tree-like structure)
    2) Better GUI:
        - use keys (e.g. F8, F7, F9) to step into, step over, go - these could be configurable
        - execution line should be automatically updated in the editor, while debugging
        - be able to interrupt the execution; the debugger will automatically stop on the next line of code
        - distinguish between "standard" globals (like __builtins__, __doc__, etc.) and the "actual" locals; have a check box whether to display the first category, like the "globals" checkbox. I ask this because most of the time I don't need to know these variables and it's counter-productive to keep my screen and attention busy with them.
    3) Eventually a place to define and view watches. In a case of a big program, there might be a lot of globals, and I'm interested in watching just a few of them.

All these features are what is normally found in most integrated debuggers, so they should be here, also. And I don't think they are actually difficult to implement ;)

Best regards
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.python.org/pipermail/idle-dev/attachments/20050610/19254553/attachment.html

From a.d.schapira at worldnet.att.net  Fri Jun 10 18:27:38 2005
From: a.d.schapira at worldnet.att.net (Al Schapira)
Date: Fri, 10 Jun 2005 12:27:38 -0400
Subject: [Idle-dev] idle -h etc
In-Reply-To: <87ll5i3nzd.fsf@hydra.bayview.thirdcreek.com>
References: <00d601c56c00$79bee2c0$88654e52@bebe>
	<87ll5i3nzd.fsf@hydra.bayview.thirdcreek.com>
Message-ID: <1118420858.1566.60.camel@ADS1>

On Thu, 2005-06-09 at 23:11, Kurt B. Kaiser wrote:
...
> 
> The one addition to the debugger I would like is the ability to
> execute an arbitrary Python statement in any stack frame at a
> breakpoint. 

I second the motion.  In fact, I suggested this to you in April '04. 
...
> What other capability do you feel is missing?

The above execution of an arbitrary Python statement at a breakpoint can
be interactively typed in (when stopped at a   breakpoint.) It should be
convenient to repeat the execution of the previously typed statement
without retyping it.

Building on this would be the *automatic* evaluation of one or more
previously entered Python statements every time a breakpoint is hit.
Each breakpoint should have associated with it one or more statements of
Python code. It should be possible to associate the same set of stored
statements with more than one breakpoint without reentering them. It
should be convenient to save and reuse the debugging statements between
debugging sessions.

This automatically provides a general (and conditional) variable
watchpoint facility -- the code associated with a breakpoint can be as
simple as a single variable (e.g. x, whose value would be printed, as if
in an interactive session) or as complex as you like. 

[Of course, one way to do this is to do nothing more than call a
user-defined function which the user must write ahead of time.  But
often you don't know what you want to look at until you are actually
debugging.]

It must be possible to enable or disable the actual execution of each
breakpoint's associated code without deleting the code. I.e. only after
I hit breakpoint #1 might I want to enable the code associated with
breakpoint #2. This is also important for performance reasons.

For the user interface of this feature, I envision an additional
subwindow of the idle window, containing a table of rows, one per
breakpoint, in which each breakpoint's associated statements and their
values would be automatically displayed when stopped. The row for the
current breakpoint (the one stopped at) should be highlighted. Each row,
(breakpoint's code & values) would have a checkbox to enable/disable
it.  The expressions associated with any breakpoint could be entered or
changed whenever idle is stopped at any breakpoint.  A button should
save all the debugging statements (rows) although if the program being
debugged is changed, the debugging statements may have to be
re-associated with the proper breakpoint(s).

Thanks for asking.

	-Al Schapira, a.d.schapira at worldnet.att.net




From noreply at sourceforge.net  Sun Jun 12 06:18:24 2005
From: noreply at sourceforge.net (SourceForge.net)
Date: Sat, 11 Jun 2005 21:18:24 -0700
Subject: [Idle-dev] [ idlefork-Bugs-763524 ] Colorizing/Beeps/Focus/Crashes
	RFE/Bugs
Message-ID: <E1DhJvU-0004yJ-Au@sc8-sf-web3.sourceforge.net>

Bugs item #763524, was opened at 2003-06-30 17:20
Message generated for change (Comment added) made by kbk
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=109579&aid=763524&group_id=9579

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: None
Group: None
Status: Open
Resolution: Accepted
Priority: 5
Submitted By: Guido van Rossum (gvanrossum)
Assigned to: Kurt B. Kaiser (kbk)
Summary: Colorizing/Beeps/Focus/Crashes RFE/Bugs

Initial Comment:
I've been using the latest version from Python CVS on
Win9: quite intensively over the last week.  Some
observations:

- When reusing a blank untitled window to edit a Text
file, it keeps using Python coloring.

- When saving a Python with a non-Python extension
(e.g. .txt), it keeps the coloring.

- When switching off coloring by saving an untitle
buffer as a non-Python extension (e.g. .txt), it keeps
existing coloring.

- When opening a file reuses a blank untitled window,
it doesn't set the focus on the window.

- I take back my earlier request to do something when
the stack viewer window can't find a traceback.  It
beeps, but I had my sound off.

- When right click -&gt; Go to file/line can't find
something, perhaps it should just beep rather than pop
up a dialog.

- Maybe anything that can't do something that's pretty
obvious should just beep?   Or maybe errors should be
displayed somehow but not require clicking OK?

- Selecting a window from the Windows menu doesn't set
the focus on the selected window!

- Keyboard shortcut for Redo (Ctl-Shift-Z) doesn't
actually work!

- Is there any way to set a breakpoint
programmatically? (the IDLE debugger equivalent of
pdb.set_trace())

- I think I crashed it by using the stack viewer after
closing the PyShell.

- It also crashed occasionally when using the debugger
(after many successful debug sessions).

- stack browser window needs title (currently says &quot;idle&quot;)

- debugger doesn't always pop up when started

- source window doesn't always pop up when double
clicking in debugger

- want a &quot;save all&quot; in file menu.

- suspending win98 has high probability of crashing
idle when a subprocess exists (?)


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

>Comment By: Kurt B. Kaiser (kbk)
Date: 2005-06-11 23:18

Message:
Logged In: YES 
user_id=149084

Python Patch 1196895 fixed the colorizing issues.

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

Comment By: Kurt B. Kaiser (kbk)
Date: 2004-08-22 00:40

Message:
Logged In: YES 
user_id=149084

Addressed the two focus issues: reuse of blank window
and Windows menu now grab focus.

Addressed the two window raising issues in debugger.

Fixed in Python IDLE 1.1a3.
WindowList.py Rev 1.6 and associated changes.

Redo shortcut was fixed in Python IDLE 1.1a1.

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

Comment By: Guido van Rossum (gvanrossum)
Date: 2003-07-01 06:40

Message:
Logged In: YES 
user_id=6380

2. There's a special feature that if you have a blank,
unchanged, untitled window (e.g. created by ^N) and then
from within that window open a file, the opened file reuses
the blank window rather than creating a new window like it
normally does. Apparently a few settings aren't correctly
set/reset in this case.

3. Agreed.

4. So true. It's fine to ignore it.

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

Comment By: Kurt B. Kaiser (kbk)
Date: 2003-07-01 01:30

Message:
Logged In: YES 
user_id=149084

1. Rather than aggravate the list with endless copies of
this tracker every time one gets fixed, I'm going to add
the items to the TODO with a final disposition here when
all fixed (or not :)
2. I can't reproduce the first item.  What does &quot;reusing a
blank, untitled...&quot; mean? Exactly what did you do to get
to that point?
3. Generally, I like a quiet interface.   I don't like dialogs
popping up when I'm just being stupid or trying something
to see if it's possible.  Beeps are ok, I just turn the sound
down.  Of course some people like to listen to music, so 
I suppose we'll need a config option at some point.
4. In my experience, suspending W98 has a high probability
of crashing, period.  I'm not sure how I'd attack that one.

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

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=109579&aid=763524&group_id=9579

From bvande at po-box.mcgill.ca  Sun Jun 12 22:18:06 2005
From: bvande at po-box.mcgill.ca (Brian van den Broek)
Date: Sun, 12 Jun 2005 16:18:06 -0400
Subject: [Idle-dev] module won't run in IDLE: puzzling traceback
In-Reply-To: <87u0kbuyh8.fsf@hydra.bayview.thirdcreek.com>
References: <427E5E17.80608@po-box.mcgill.ca>
	<87u0kbuyh8.fsf@hydra.bayview.thirdcreek.com>
Message-ID: <42AC987E.6000608@po-box.mcgill.ca>

Kurt B. Kaiser said unto the world upon 06/06/2005 14:33:
> Brian van den Broek <bvande at po-box.mcgill.ca> writes:
> 
> 
>>I'm a hobbyist who posts mostly to Tutor; I'm doing my level best to 
>>handle this "right". Apologies for any mis-steps. I have googled the 
>>web and searched the gmane archive of this list for the terms 
>>asyncqueue and putmessage but did not come up with anything that I 
>>recognized as relevant.
> 
> 
> Thanks!  You're definitely on the right track!
> 
> 
>>The problem:
>>
>>I have a module which, when I run it with IDLE 1.1.1 produces the 
>>following traceback:
>>
>>IDLE 1.1.1
>> >>> ================================ RESTART 
>>================================
>> >>>
>>Traceback (most recent call last):
>>   File "C:\PYTHON24\lib\idlelib\rpc.py", line 233, in asyncqueue
>>     self.putmessage((seq, request))
>>   File "C:\PYTHON24\lib\idlelib\rpc.py", line 333, in putmessage
>>     raise IOError
>>IOError
> 

<snip further details of my problem and several suggestions from Kurt>


Hi Kurt and all,

thanks for the reply, Kurt, and apologies for the delay in my response.

The day before you posted, my laptop (and sole computer) up and died. 
So, I was off-line until I got the replacement yesterday. Cursory 
efforts to reproduce the problem on the new WinXP box have not 
succeeded (though, in context, failure is success ;-)

My thesis is due at the end of August, and the recent lack of a 
computer through a bit of a wrench in my schedule! So, at the moment, 
the cursory attempts will have to do. When I've time to breath, I will 
put a sustained effort into an attempt to reproduce the problem, and 
post back if I can do so.

Thanks again for your efforts. Best,

Brian vdB



From hernan at orgmf.com.ar  Mon Jun 13 20:32:22 2005
From: hernan at orgmf.com.ar (=?us-ascii?Q?Hernan_Martinez_Foffani?=)
Date: Mon, 13 Jun 2005 20:32:22 +0200
Subject: [Idle-dev] idle -h etc
In-Reply-To: <1118420858.1566.60.camel@ADS1>
Message-ID: <EMELLMOMDNIMCIGOAHLNAEOACNAA.hernan@orgmf.com.ar>

>> What other capability do you feel is missing?

Just because you've asked, my wish list is:
- A config option to set the current working
  directory on shell startup.
- That IDLE detects itself running and open
  another window instead of another process
  when I rightclick on a script (Windows OS).
- A config option that hides the shell when I
  start IDLE for editing a file.
- Intelligent copy&paste of code snippets from
  browsers or ascii editors to idle's shell and back
  magically handling PS1/PS2 and tabs/spaces.
- copy&paste code snippets from shell to edit
  windows as docstrings.

- the concept of a project integrated in IDLE
- subversion and/or generic SCM plugin capabilities.
mmm... no...  may be the last two belong to an third
party tool that could use IDLE as an editor/debugger?

Regards,
-Hernan.

ah... also change the Tk logo! :-)
yes, I know :(


From alin.moldoveanu at rdslink.ro  Wed Jun 15 09:38:29 2005
From: alin.moldoveanu at rdslink.ro (Alin Moldoveanu)
Date: Wed, 15 Jun 2005 10:38:29 +0300
Subject: [Idle-dev] idle - ...
Message-ID: <002901c5717d$39807de0$88654e52@bebe>

I subscribe to the following list of IDLE behavior:
    - IDLE detects itself running and open  another window instead of
another process when started to edit a script
    - if that script is already opened, is shouldn't be opened again, just
its window brought to front
    - more debugging facilities


From dooms at info.ucl.ac.be  Wed Jun 15 09:42:32 2005
From: dooms at info.ucl.ac.be (=?ISO-8859-1?Q?Gr=E9goire_Dooms?=)
Date: Wed, 15 Jun 2005 09:42:32 +0200
Subject: [Idle-dev] idle -h etc
In-Reply-To: <1118420858.1566.60.camel@ADS1>
References: <00d601c56c00$79bee2c0$88654e52@bebe>	<87ll5i3nzd.fsf@hydra.bayview.thirdcreek.com>
	<1118420858.1566.60.camel@ADS1>
Message-ID: <42AFDBE8.8030908@info.ucl.ac.be>

Al Schapira wrote:

>On Thu, 2005-06-09 at 23:11, Kurt B. Kaiser wrote:
>...
>  
>
>>The one addition to the debugger I would like is the ability to
>>execute an arbitrary Python statement in any stack frame at a
>>breakpoint. 
>>    
>>
>
>I second the motion.  In fact, I suggested this to you in April '04. 
>...
>  
>
>>What other capability do you feel is missing?
>>    
>>
>
>The above execution of an arbitrary Python statement at a breakpoint can
>be interactively typed in (when stopped at a   breakpoint.) It should be
>convenient to repeat the execution of the previously typed statement
>without retyping it.
>
>Building on this would be the *automatic* evaluation of one or more
>previously entered Python statements every time a breakpoint is hit.
>  
>
Interresting ... see my patch for pdb at:

http://sourceforge.net/tracker/?group_id=5470&atid=305470&func=detail&aid=790710

It implements breakpoint command lists in pdb with the same interface as
in gdb.
--
Gr?goire Dooms




From kbk at shore.net  Thu Jun 16 07:14:11 2005
From: kbk at shore.net (Kurt B. Kaiser)
Date: Thu, 16 Jun 2005 01:14:11 -0400
Subject: [Idle-dev] idle - ...
In-Reply-To: <002901c5717d$39807de0$88654e52@bebe> (Alin Moldoveanu's
	message of "Wed, 15 Jun 2005 10:38:29 +0300")
References: <002901c5717d$39807de0$88654e52@bebe>
Message-ID: <87oea6vq70.fsf@hydra.bayview.thirdcreek.com>

"Alin Moldoveanu" <alin.moldoveanu at rdslink.ro> writes:

> I subscribe to the following list of IDLE behavior:
>     - IDLE detects itself running and open another window instead of
> another process when started to edit a script
>     - if that script is already opened, is shouldn't be opened again,
> just its window brought to front

I guess you are referring to the situation when you initiate an edit
by right clicking on a Python file and letting Windows start up
another copy of IDLE via the file association?  That seems difficult:
how do you (in a cross-platform way) signal the running process to
open a new edit window or raise the existing one?  I'd use IDLE's file
menu to open files if you are going to do any serious editing.  Then
there will be only one process.  Besides, if you right click you are
running without the subprocess because of (hopefully) temporary
limitations on running multiple copies of IDLE with their
subprocesses.  If you open files with the file menu, IDLE functions
as you suggested.

I don't recommend running w/o the subprocess unless you have a
specific need, e.g. you are using IDLE to develop IDLE and you don't
want to keep reopening your source file.  In that case, edit the IDLE
source with a copy of IDLE started with the -n switch, and test using
the normal IDLE with subprocess.  That way, if you blow up IDLE you
usually don't have to switch to Notepad or something to get things
running again.

File / Recent Files is your friend.

>     - more debugging facilities

Yes, but still simple.  At the level of pdb.  It doesn't seem
worthwhile (to me, anyway) to put a lot of effort into a fancy
debugger since I really don't find that much use for one in Python.
I would like to be able to examine the stack frames, though, and
de-cluttering the class browser would be helpful.

Also, IDLE's design concept is KISS: the interface should /appear/
minimalistic, not a clone of e.g. Visual Studio.  IDLE should be
useful for the widest possible range of users: accessible for
beginners and more than adequate for experts.  That's my goal, at
least.

Thanks to everyone for the comments.
-- 
KBK

From kbk at shore.net  Thu Jun 16 08:10:30 2005
From: kbk at shore.net (Kurt B. Kaiser)
Date: Thu, 16 Jun 2005 02:10:30 -0400
Subject: [Idle-dev] idle -h etc
In-Reply-To: <EMELLMOMDNIMCIGOAHLNAEOACNAA.hernan@orgmf.com.ar> (Hernan
	Martinez Foffani's message of "Mon, 13 Jun 2005 20:32:22 +0200")
References: <EMELLMOMDNIMCIGOAHLNAEOACNAA.hernan@orgmf.com.ar>
Message-ID: <87fyvivnl5.fsf@hydra.bayview.thirdcreek.com>

Hernan Martinez Foffani <hernan at orgmf.com.ar> writes:

>>> What other capability do you feel is missing?
>
> Just because you've asked, my wish list is:
> - A config option to set the current working
>   directory on shell startup.

It already does this for me.

> - That IDLE detects itself running and open
>   another window instead of another process
>   when I rightclick on a script (Windows OS).

As I said in my previous email, that seems hard, especially on
Windows.  Suggestions will be appreciated.

> 
> - A config option that hides the shell when I start IDLE for editing
> a file.

Yes.  I am thinking of changing the -e and -i switches to override
the configuration files.  Then the right click would work better
on Windows.

> - Intelligent copy&paste of code snippets from browsers or ascii
> editors to idle's shell and back magically handling PS1/PS2 and
> tabs/spaces.  

Would be nice.

> - copy&paste code snippets from shell to edit windows as docstrings.

What would this be used for?  Is it worth the effort and complication
to eliminate typing a couple of triple quotes once in awhile?

> - the concept of a project integrated in IDLE

This could happen if people on the list could get together on a
(KISS :-) design.

> - subversion and/or generic SCM plugin capabilities.

I looked at this briefly.  The tools are so complex that integrating
anything more than the simplest functions (update, checkin) would
appear to be a big job and would clutter IDLE.  You would probably
still have to use the tool outside IDLE for branching and merging.
Have you tried TortiseCVS?  It seems to run well alongside IDLE.  It
has a pretty elaborate GUI in order to cover everything, and it's 
nicely integrated with Windows Explorer.

I use command line CVS with a couple of scripts (e.g. 'd' to get a cvs
unidiff of a file) for frequent commands in a separate xterm on Unix,
and I've never even felt the need to use emacs cvs mode.

I keep notes on the more complex manipulations because they aren't
done very often. Cut/paste between the notes and the command line 
works well for me, and command line history retrieval does the rest.

Maybe an extension, or multiple extensions, would be the way to go.
But I subscribe to the Unix philosophy of separate, optimized tools
rather than an integrated mediocrity.  And that way people get to
choose the tools which best suit their preferences.

I'm open to ideas on this.

-- 
KBK

From hernan at orgmf.com.ar  Thu Jun 16 12:52:34 2005
From: hernan at orgmf.com.ar (=?us-ascii?Q?Hernan_Martinez_Foffani?=)
Date: Thu, 16 Jun 2005 12:52:34 +0200
Subject: [Idle-dev] idle -h etc
In-Reply-To: <87fyvivnl5.fsf@hydra.bayview.thirdcreek.com>
Message-ID: <EMELLMOMDNIMCIGOAHLNMEBGCOAA.hernan@orgmf.com.ar>

Please, consider all my RFEs with a broad perspective.
The absence of these neither annoys nor bothers me.  It just
happens to raise a "it would be nice if ..." thinking
sometimes.

>>>> What other capability do you feel is missing?
>> 
>> Just because you've asked, my wish list is:
>> - A config option to set the current working
>>   directory on shell startup.
> 
> It already does this for me.

Ah...  In 2.4 maybe?  Apologize then.  I'm still using 2.3.

>> - That IDLE detects itself running and open
>>   another window instead of another process
>>   when I rightclick on a script (Windows OS).
> 
> As I said in my previous email, that seems hard, especially on
> Windows.  Suggestions will be appreciated.

Yes, I also believe it would be hard.  It may be a bit easier if
IDLE can test the presence of pywin32 and use some Windows primitives
in that case (don't know if that is no-no policy wrt IDLE project.)

>> - Intelligent copy&paste of code snippets from browsers or ascii
>> editors to idle's shell and back magically handling PS1/PS2 and
>> tabs/spaces.  
>
>Would be nice.

Glad to hear that.

>> - copy&paste code snippets from shell to edit windows as docstrings.
> 
> What would this be used for?  Is it worth the effort and complication
> to eliminate typing a couple of triple quotes once in awhile?

My use case is for doctests.   If it can take care of PS1/PS2 while
pasting it would great.  (for instance, idle opens a pop context menu
and offers to choice for "Paste as doctest", "Paste from browser", etc.)

I leave to you the task of measuring the "effort worthness". ;-)

>> - the concept of a project integrated in IDLE
> 
> This could happen if people on the list could get together on a
> (KISS :-) design.

For me a project is just a list of files and directories and a gadget
that detects renames, moves and deletes on such list.  The list
can be loaded, modified in an IDLE session and saved for later use.

>> - subversion and/or generic SCM plugin capabilities.
> 
> I looked at this briefly.  The tools are so complex that integrating
> anything more than the simplest functions (update, checkin) would
> appear to be a big job and would clutter IDLE.  You would probably
> still have to use the tool outside IDLE for branching and merging.
> Have you tried TortiseCVS?  It seems to run well alongside IDLE.  It
> has a pretty elaborate GUI in order to cover everything, and it's
> nicely integrated with Windows Explorer.

Sure.  Actually I'm using TortoiseSVN every day.  And even sometimes
I fallback to Subversion's CLI for some operations (merge being one
of them).
We develop with Visual Studio (we are a .NET company) and we've got 
a Subversion plugin for it.  The plugin's advantage over other
clients is that it knows which files belongs to the project.
Committing then is a bit safer because it's less likely that you
forget files or include unrelated ones.  
But the plugin still has problems.  It has to track renames, moves,
deletes and additions and VS's event API doesn't alert subscriptors
on every case.  The result is that I have to use external tools
every now and then (TortoiseSVN, and the official Subversion's CLI)

In summary, I think it would be cool to have that integregated
but only if the design and implementation consider all the corner
cases.  Otherwise I rather keep using external tools.  

BTW, thanks for asking, Kurt.

Regards,
-H.


From kbk at shore.net  Thu Jun 16 20:06:10 2005
From: kbk at shore.net (Kurt B. Kaiser)
Date: Thu, 16 Jun 2005 14:06:10 -0400
Subject: [Idle-dev] idle -h etc
In-Reply-To: <EMELLMOMDNIMCIGOAHLNMEBGCOAA.hernan@orgmf.com.ar> (Hernan
	Martinez Foffani's message of "Thu, 16 Jun 2005 12:52:34 +0200")
References: <EMELLMOMDNIMCIGOAHLNMEBGCOAA.hernan@orgmf.com.ar>
Message-ID: <8764weuqgd.fsf@hydra.bayview.thirdcreek.com>

Hernan Martinez Foffani <hernan at orgmf.com.ar> writes:

>>> Just because you've asked, my wish list is:
>>> - A config option to set the current working
>>>   directory on shell startup.
>> 
>> It already does this for me.
>
> Ah...  In 2.4 maybe?  Apologize then.  I'm still using 2.3.

According to IDLE's NEWS.txt, it appears that the functionality
changed before 2.3.1.

Using the command line, when I cd to some directory and open IDLE,
that directory is prepended to sys.path.  If I use File / Open, the
file browser starts in that directory.  If I open a module somewhere
else, the start point of the file browser is changed to the directory
of the module, but os.path.curdir is unchanged until modified by
os.chdir().

When using the Windows Start menu, the startup directory for IDLE can
be modified by changing the IDLE launcher Properties Start In: value.

I probably don't understand your request yet.  Please describe in
detail what you are experiencing and what you are looking for.

If there was a 'project' feature, would each project want to have
its own starting directory?

-- 
KBK

From hernan at orgmf.com.ar  Thu Jun 16 21:33:47 2005
From: hernan at orgmf.com.ar (=?us-ascii?Q?Hernan_Martinez_Foffani?=)
Date: Thu, 16 Jun 2005 21:33:47 +0200
Subject: [Idle-dev] idle -h etc
In-Reply-To: <8764weuqgd.fsf@hydra.bayview.thirdcreek.com>
Message-ID: <HPEBIMANNCHHDMDBGCHHMEMPFAAA.hernan@orgmf.com.ar>

>>>> - A config option to set the current working
>>>>   directory on shell startup.
>
> Using the command line, when I cd to some directory and open IDLE,
> that directory is prepended to sys.path.  If I use File / Open, the
> file browser starts in that directory.  If I open a module somewhere
> else, the start point of the file browser is changed to the directory
> of the module, but os.path.curdir is unchanged until modified by
> os.chdir(). 

This is ok for me.  It's intuitive enough that I don't have to
remember the behaviour.

I was refering to:

> When using the Windows Start menu, the startup directory for IDLE can
> be modified by changing the IDLE launcher Properties Start In: value.

If I could choose I rather not change the installed shortcuts.
;-)

> If there was a 'project' feature, would each project want to have its
> own starting directory? 

mm...  no.  I think it won't be needed.  It's enough if it
works like it does for File/Open today.

-H.