From cheselka@theriver.com  Thu Jun  7 15:01:51 2001
From: cheselka@theriver.com (Matthew Cheselka)
Date: Thu, 07 Jun 2001 07:01:51 -0700
Subject: [Idle-dev] problem with IDLE in Windows NT
Message-ID: <3B1F894F.BF1C11EA@theriver.com>

Good day.

I've installed Python 1.5.2 on my Windows NT machine and I would like to
be able to use IDLE.  So I go to Start->Programs->Python1.5->IDLE
(Python GUI) and I get this message in a pop-up window with the title
"C:Program Files\Python\Tools\idle\idle.pyw":

    Access to the specified device, path, or file is denied

What gives??

M



From guido@digicool.com  Thu Jun  7 16:00:39 2001
From: guido@digicool.com (Guido van Rossum)
Date: Thu, 07 Jun 2001 11:00:39 -0400
Subject: [Idle-dev] problem with IDLE in Windows NT
In-Reply-To: Your message of "Thu, 07 Jun 2001 07:01:51 PDT."
 <3B1F894F.BF1C11EA@theriver.com>
References: <3B1F894F.BF1C11EA@theriver.com>
Message-ID: <200106071500.f57F0dl04493@odiug.digicool.com>

> Good day.
> 
> I've installed Python 1.5.2 on my Windows NT machine and I would like to
> be able to use IDLE.  So I go to Start->Programs->Python1.5->IDLE
> (Python GUI) and I get this message in a pop-up window with the title
> "C:Program Files\Python\Tools\idle\idle.pyw":
> 
>     Access to the specified device, path, or file is denied
> 
> What gives??
> 
> M

No idea.  It all depends on your system setup and the choices you made
when installing Python.

I would recommend to upgrade to Python 2.1 though; the invocation of
IDLE there is more robust.  The version of IDLE is better too.

--Guido van Rossum (home page: http://www.python.org/~guido/)


From mats@laplaza.org  Mon Jun 11 22:21:19 2001
From: mats@laplaza.org (Mats Wichmann)
Date: Mon, 11 Jun 2001 15:21:19 -0600
Subject: [Idle-dev] Foolish consistency?
In-Reply-To: <200012272233.RAA22707@cj20424-a.reston1.va.home.com>
References: <Your message of "Wed, 20 Dec 2000 14:01:15 MST." <5.0.0.25.1.20001220135643.0103e050@mail.laplaza.org>
 <Pine.LNX.4.21.0012201448280.5612-100000@zaibach.twistedmatrix.com>
 <14912.65004.447723.799592@cj42289-a.reston1.va.home.com>
 <Pine.LNX.4.21.0012201448280.5612-100000@zaibach.twistedmatrix.com>
 <5.0.0.25.1.20001220135643.0103e050@mail.laplaza.org>
Message-ID: <5.1.0.14.1.20010611151723.00aa5aa0@laplaza.org>

Just wondering...

How come in the IDLE "shell window" automatice indents
are by way of tabs, and in the IDLE "editor window"
they are by way of multiples of four spaces (no tabs).

Is there a reason why these two should not follow
the same convention?



From pobrien@orbtech.com  Mon Jun 11 23:01:37 2001
From: pobrien@orbtech.com (Patrick K. O'Brien)
Date: Mon, 11 Jun 2001 17:01:37 -0500
Subject: [Idle-dev] Windows SendTo
Message-ID: <NBBBIOJPGKJEKIECEMCBIEDPKAAA.pobrien@orbtech.com>

I'd like to be able to add IDLE to my SendTo list under windows so I can
right click on a .py file, select SendTo, IDLE and have IDLE open the file
up in an editor window. I can add notepad, excel, PFE and so forth to my
SendTo list but I can't get it to work with IDLE. Is this possible?

---
Patrick K. O'Brien
Orbtech
"I am, therefore I think."




From pobrien@orbtech.com  Mon Jun 11 23:32:38 2001
From: pobrien@orbtech.com (Patrick K. O'Brien)
Date: Mon, 11 Jun 2001 17:32:38 -0500
Subject: [Idle-dev] Why are keybindings case sensitive?
Message-ID: <NBBBIOJPGKJEKIECEMCBGEEBKAAA.pobrien@orbtech.com>

Or rather, why aren't any of the keybindings (especially cut, copy and
paste) setup to work when one has caps lock on? I fixed this in my version
of keydefs.py but this seems like something that IDLE should do by default.
Here is the change I made, adding uppercase keybindings. It appears to work
fine.

windows_keydefs = \
{'<<Copy>>': ['<Control-c>', '<Control-C>'],
 '<<Cut>>': ['<Control-x>', '<Control-X>'],
 '<<Paste>>': ['<Control-v>', '<Control-V>'],

---
Patrick K. O'Brien
Orbtech
"I am, therefore I think."




From rogue_pedro@yahoo.com  Tue Jun 12 00:21:13 2001
From: rogue_pedro@yahoo.com (Pedro Kahn)
Date: Mon, 11 Jun 2001 16:21:13 -0700 (PDT)
Subject: [Idle-dev] Foolish consistency?
In-Reply-To: <5.1.0.14.1.20010611151723.00aa5aa0@laplaza.org>
Message-ID: <20010611232113.27937.qmail@web14507.mail.yahoo.com>

My first post to this list, please correct me on any
gaffs.

--- Mats Wichmann <mats@laplaza.org> wrote:
> 
> Just wondering...
> 
> How come in the IDLE "shell window" automatice
> indents
> are by way of tabs, and in the IDLE "editor window"
> they are by way of multiples of four spaces (no
> tabs).

I'm pretty sure that the shell windows use tabs to
conform more closely to the behavior of a "normal"
console interaction, where tabs are used pretty
strictly for scope (or logical level or whatever it's
called)

In the Editor windows, well it might have something to
do with Tk having a fixed tabwidth, there's more
information in the AutoIndent.py in the IDLE source.
There is an entry in config.txt called [AutoIndent]
underwhich you might try putting "usetabs=0" or
something..  have fun.
> 
> Is there a reason why these two should not follow
> the same convention?

dunno

__________________________________________________
Do You Yahoo!?
Get personalized email addresses from Yahoo! Mail - only $35 
a year!  http://personal.mail.yahoo.com/


From guido@digicool.com  Tue Jun 12 01:28:25 2001
From: guido@digicool.com (Guido van Rossum)
Date: Mon, 11 Jun 2001 20:28:25 -0400
Subject: [Idle-dev] Why are keybindings case sensitive?
In-Reply-To: Your message of "Mon, 11 Jun 2001 17:32:38 CDT."
 <NBBBIOJPGKJEKIECEMCBGEEBKAAA.pobrien@orbtech.com>
References: <NBBBIOJPGKJEKIECEMCBGEEBKAAA.pobrien@orbtech.com>
Message-ID: <200106120028.UAA04502@cj20424-a.reston1.va.home.com>

> Or rather, why aren't any of the keybindings (especially cut, copy and
> paste) setup to work when one has caps lock on? I fixed this in my version
> of keydefs.py but this seems like something that IDLE should do by default.
> Here is the change I made, adding uppercase keybindings. It appears to work
> fine.
> 
> windows_keydefs = \
> {'<<Copy>>': ['<Control-c>', '<Control-C>'],
>  '<<Cut>>': ['<Control-x>', '<Control-X>'],
>  '<<Paste>>': ['<Control-v>', '<Control-V>'],

An oversight.  Thanks for the fix!

--Guido van Rossum (home page: http://www.python.org/~guido/)


From guido@digicool.com  Tue Jun 12 01:33:18 2001
From: guido@digicool.com (Guido van Rossum)
Date: Mon, 11 Jun 2001 20:33:18 -0400
Subject: [Idle-dev] Foolish consistency?
In-Reply-To: Your message of "Mon, 11 Jun 2001 15:21:19 MDT."
 <5.1.0.14.1.20010611151723.00aa5aa0@laplaza.org>
References: <Your message of "Wed, 20 Dec 2000 14:01:15 MST." <5.0.0.25.1.20001220135643.0103e050@mail.laplaza.org> <Pine.LNX.4.21.0012201448280.5612-100000@zaibach.twistedmatrix.com> <14912.65004.447723.799592@cj42289-a.reston1.va.home.com> <Pine.LNX.4.21.0012201448280.5612-100000@zaibach.twistedmatrix.com> <5.0.0.25.1.20001220135643.0103e050@mail.laplaza.org>
 <5.1.0.14.1.20010611151723.00aa5aa0@laplaza.org>
Message-ID: <200106120033.UAA04536@cj20424-a.reston1.va.home.com>

> Just wondering...
> 
> How come in the IDLE "shell window" automatice indents
> are by way of tabs, and in the IDLE "editor window"
> they are by way of multiples of four spaces (no tabs).
> 
> Is there a reason why these two should not follow
> the same convention?

It's a per-window option.  I chose the default to be tabs in the Shell
window because of the prompt: if it was 4 spaces there, your code
would look like this:

    >>> if x < 10:
	print y

which appears not indented right to some beginners.  With a tab it
looks like this:

    >>> if x < 10:
            print y

which is unambiguous.

For other windows the default is 4 spaces, which is more practical.

--Guido van Rossum (home page: http://www.python.org/~guido/)


From pobrien@orbtech.com  Tue Jun 12 03:55:05 2001
From: pobrien@orbtech.com (Patrick K. O'Brien)
Date: Mon, 11 Jun 2001 21:55:05 -0500
Subject: [Idle-dev] Weird error when pydoc.help is added to builtin from site.py
Message-ID: <NBBBIOJPGKJEKIECEMCBEEEGKAAA.pobrien@orbtech.com>

Here is a problem we discovered on the python-edu list. We are trying to add
pydoc help to the python environment by adding the following code to
site.py:

from pydoc import help
import __builtin__
__builtin__.help = help
del help
del __builtin__

For the most part this works. For example, in IDLE, you can do help(len) and
get the expected information. But try help with no value and you get the
following:

>>> help
Traceback (most recent call last):
  File "<interactive input>", line 1, in ?
  File "c:\python21\lib\pydoc.py", line 1276, in __repr__
    self()
  File "c:\python21\lib\pydoc.py", line 1285, in __call__
    self.interact()
  File "c:\python21\lib\pydoc.py", line 1297, in interact
    self.output.flush()
IOError: [Errno 9] Bad file descriptor

Any idea what the problem might be? And if we can get it to work, how do you
feel about introducing this as a PEP for Python? There is something of a
precedent in the existing code that defines "quit" and "exit". So it would
seem to make sense to define "help" as well.

--- snipped from site.py as support for PEP XXXXX ---

# Define new built-ins 'quit' and 'exit'.
# These are simply strings that display a hint on how to exit.
if os.sep == ':':
    exit = 'Use Cmd-Q to quit.'
elif os.sep == '\\':
    exit = 'Use Ctrl-Z plus Return to exit.'
else:
    exit = 'Use Ctrl-D (i.e. EOF) to exit.'
import __builtin__
__builtin__.quit = __builtin__.exit = exit
del exit

---
Patrick K. O'Brien
Orbtech
"I am, therefore I think."




From kbk@float.ne.mediaone.com  Tue Jun 12 04:03:31 2001
From: kbk@float.ne.mediaone.com (Kurt B. Kaiser)
Date: 11 Jun 2001 23:03:31 -0400
Subject: [Idle-dev] Foolish consistency?
In-Reply-To: <200106120033.UAA04536@cj20424-a.reston1.va.home.com>
References: <Your message of "Wed, 20 Dec 2000 14:01:15 MST."
 <5.0.0.25.1.20001220135643.0103e050@mail.laplaza.org>
 <Pine.LNX.4.21.0012201448280.5612-100000@zaibach.twistedmatrix.com>
 <14912.65004.447723.799592@cj42289-a.reston1.va.home.com>
 <Pine.LNX.4.21.0012201448280.5612-100000@zaibach.twistedmatrix.com>
 <5.0.0.25.1.20001220135643.0103e050@mail.laplaza.org>
 <5.1.0.14.1.20010611151723.00aa5aa0@laplaza.org>
 <200106120033.UAA04536@cj20424-a.reston1.va.home.com>
Message-ID: <m3elsqz9fg.fsf@float.ne.mediaone.com>

Although it's true the first level is apparently 4 spaces indented due to the
tab from the left margin, the next level is the equivalent of 8 spaces in due
to the next tab:

>>> def foo():
        if (1):
                a=3

Regards, KBK



From guido@digicool.com  Tue Jun 12 15:05:02 2001
From: guido@digicool.com (Guido van Rossum)
Date: Tue, 12 Jun 2001 10:05:02 -0400
Subject: [Idle-dev] Weird error when pydoc.help is added to builtin from site.py
In-Reply-To: Your message of "Mon, 11 Jun 2001 21:55:05 CDT."
 <NBBBIOJPGKJEKIECEMCBEEEGKAAA.pobrien@orbtech.com>
References: <NBBBIOJPGKJEKIECEMCBEEEGKAAA.pobrien@orbtech.com>
Message-ID: <200106121405.f5CE52s25017@odiug.digicool.com>

> Here is a problem we discovered on the python-edu list. We are trying to add
> pydoc help to the python environment by adding the following code to
> site.py:
> 
> from pydoc import help
> import __builtin__
> __builtin__.help = help
> del help
> del __builtin__
> 
> For the most part this works. For example, in IDLE, you can do help(len) and
> get the expected information. But try help with no value and you get the
> following:
> 
> >>> help
> Traceback (most recent call last):
>   File "<interactive input>", line 1, in ?
>   File "c:\python21\lib\pydoc.py", line 1276, in __repr__
>     self()
>   File "c:\python21\lib\pydoc.py", line 1285, in __call__
>     self.interact()
>   File "c:\python21\lib\pydoc.py", line 1297, in interact
>     self.output.flush()
> IOError: [Errno 9] Bad file descriptor

Hm, this works for me in Python 2.2a0.  Which versions of Python, IDLE
and pydoc are you using?  Perhaps you have to reserach the problem
more to find out what's the matter.  Could it be the PAGER environment
variable?

> Any idea what the problem might be? And if we can get it to work, how do you
> feel about introducing this as a PEP for Python? There is something of a
> precedent in the existing code that defines "quit" and "exit". So it would
> seem to make sense to define "help" as well.
> 
> --- snipped from site.py as support for PEP XXXXX ---
> 
> # Define new built-ins 'quit' and 'exit'.
> # These are simply strings that display a hint on how to exit.
> if os.sep == ':':
>     exit = 'Use Cmd-Q to quit.'
> elif os.sep == '\\':
>     exit = 'Use Ctrl-Z plus Return to exit.'
> else:
>     exit = 'Use Ctrl-D (i.e. EOF) to exit.'
> import __builtin__
> __builtin__.quit = __builtin__.exit = exit
> del exit
> 
> ---
> Patrick K. O'Brien

There are some problems with doing it this way: the pydoc module is
too big to be imported by site.py.  Ping has suggested that some kind
of lightweight 'bootstrap' code should be included in site.py.  I am
in favor of that, but I'm waiting for someone else to submit a
patch...

--Guido van Rossum (home page: http://www.python.org/~guido/)


From ping@lfw.org  Tue Jun 12 15:18:03 2001
From: ping@lfw.org (Ka-Ping Yee)
Date: Tue, 12 Jun 2001 16:18:03 +0200 (CEST)
Subject: [Idle-dev] Weird error when pydoc.help is added to builtin from
 site.py
In-Reply-To: <200106121405.f5CE52s25017@odiug.digicool.com>
Message-ID: <Pine.LNX.4.32.0106121611350.3849-100000@ziggy.localdomain.fake>

Patrick K. O'Brien wrote:
> Here is a problem we discovered on the python-edu list. We are trying to add
> pydoc help to the python environment by adding the following code to
> site.py:
>
> from pydoc import help
> import __builtin__
> __builtin__.help = help
> del help
> del __builtin__

Guido van Rossum wrote:
> There are some problems with doing it this way: the pydoc module is
> too big to be imported by site.py.  Ping has suggested that some kind
> of lightweight 'bootstrap' code should be included in site.py.  I am
> in favor of that, but I'm waiting for someone else to submit a
> patch...

Did you mean someone other than me?  Anyway, for reference, here is
the bootstrap code i initially proposed for site.py when pydoc was
being checked in:

    # Define the built-in object "help" to provide interactive help.
    class Helper:
        def __repr__(self):
            import inspect
            if inspect.stack()[1][3] == '?': # not called from a function
                self()
                return ''
            return '<Helper instance>'
        def __call__(self, arg=None):
            import pydoc
            pydoc.help(arg)
    __builtin__.help = Helper()


The check on

    inspect.stack()[1][3] == '?'

is a bit strange-looking, and could also be expressed as

    sys._getframe().f_code.co_name == '?'

The point of this check is to make sure that we go into interactive
mode only when "help" is typed directly at the top level.  If the
representation of "help" is otherwise obtained, for example:

    def f():
        print help
    f()

then the check on f_code.co_name prevents us from going into
interactive help.  Without this check, you would get a lot of strange
behaviour (e.g. the console would hang waiting for input whenever
anyone tries to inspect the "help" variable).


-- ?!ng

"If I have seen farther than others, it is because I was standing on a
really big heap of midgets."
    -- K. Eric Drexler



From pobrien@orbtech.com  Tue Jun 12 15:57:06 2001
From: pobrien@orbtech.com (Patrick K. O'Brien)
Date: Tue, 12 Jun 2001 09:57:06 -0500
Subject: [Edu-sig] Re: [Idle-dev] Weird error when pydoc.help is added to builtin from site.py
In-Reply-To: <200106121405.f5CE52s25017@odiug.digicool.com>
Message-ID: <NBBBIOJPGKJEKIECEMCBCEFGKAAA.pobrien@orbtech.com>

Sorry, I should have specified the environment. I'm running the Python, IDLE
and pydoc versions that come with the Python 2.1 for windows file from
python.org. I'm running under a completely up-to-date Win98SE. (I know, I
know, but please don't groan. At least I can still play games. And I do have
a Linux partition. <wink>)

Python 2.1 (#15, Apr 16 2001, 18:25:49) [MSC 32 bit (Intel)] on win32
Type "copyright", "credits" or "license" for more information.
IDLE 0.8 -- press F1 for help

I can try to track the problem further if you like, but I feel a bit out of
my league compared to those with more Python experience than I have, which
is close to zero (but catching on quickly, I hope.).
---
Patrick K. O'Brien
Orbtech
"I am, therefore I think."

-----Original Message-----
From: edu-sig-admin@python.org [mailto:edu-sig-admin@python.org]On Behalf Of
Guido van Rossum
Sent: Tuesday, June 12, 2001 9:05 AM
To: pobrien@orbtech.com
Cc: IDLE Developers List; ping@lfw.org; Python Edu SIG
Subject: [Edu-sig] Re: [Idle-dev] Weird error when pydoc.help is added to
builtin from site.py

Hm, this works for me in Python 2.2a0.  Which versions of Python, IDLE
and pydoc are you using?  Perhaps you have to reserach the problem
more to find out what's the matter.  Could it be the PAGER environment
variable?

--Guido van Rossum (home page: http://www.python.org/~guido/)

_______________________________________________
Edu-sig mailing list
Edu-sig@python.org
http://mail.python.org/mailman/listinfo/edu-sig



From guido@digicool.com  Tue Jun 12 16:20:18 2001
From: guido@digicool.com (Guido van Rossum)
Date: Tue, 12 Jun 2001 11:20:18 -0400
Subject: [Edu-sig] Re: [Idle-dev] Weird error when pydoc.help is added to builtin from site.py
In-Reply-To: Your message of "Tue, 12 Jun 2001 09:57:06 CDT."
 <NBBBIOJPGKJEKIECEMCBCEFGKAAA.pobrien@orbtech.com>
References: <NBBBIOJPGKJEKIECEMCBCEFGKAAA.pobrien@orbtech.com>
Message-ID: <200106121520.f5CFKII25370@odiug.digicool.com>

> Sorry, I should have specified the environment. I'm running the Python, IDLE
> and pydoc versions that come with the Python 2.1 for windows file from
> python.org. I'm running under a completely up-to-date Win98SE. (I know, I
> know, but please don't groan. At least I can still play games. And I do have
> a Linux partition. <wink>)

That's similar to what I have on my laptop.

> Python 2.1 (#15, Apr 16 2001, 18:25:49) [MSC 32 bit (Intel)] on win32
> Type "copyright", "credits" or "license" for more information.
> IDLE 0.8 -- press F1 for help
> 
> I can try to track the problem further if you like, but I feel a bit out of
> my league compared to those with more Python experience than I have, which
> is close to zero (but catching on quickly, I hope.).

Well, but you have one big advantage: access to the machine!  It works
fine for me.  See if this also breaks when you do this in IDLE:

  >>> import pydoc
  >>> pydoc.help()

That eliminates the manipulation with __builtin__ as the cause of the
problem.  Then you'll have to step through the code or use pdb.pm() to
find out what was wrong...

--Guido van Rossum (home page: http://www.python.org/~guido/)


From pobrien@orbtech.com  Tue Jun 12 16:46:34 2001
From: pobrien@orbtech.com (Patrick K. O'Brien)
Date: Tue, 12 Jun 2001 10:46:34 -0500
Subject: [Edu-sig] Re: [Idle-dev] Weird error when pydoc.help is added to builtin from site.py
In-Reply-To: <200106121520.f5CFKII25370@odiug.digicool.com>
Message-ID: <NBBBIOJPGKJEKIECEMCBMEFHKAAA.pobrien@orbtech.com>

Import pydoc; pydoc.help definitely works. In fact, adding help to the
builtins works from my PYTHONSTARTUP file or interactively, but not from
site.py. That's what made it so weird, at least to me. But getting it loaded
as part of site was our goal. I'll step through the code when I get a spare
hour (or two or three <g>).

>>> import __builtin__
>>> from pydoc import help
>>> __builtin__.help = help
>>> del help
>>> del __builtin__
>>> help

Welcome to Python 2.1!  This is the online help utility.

If this is your first time using Python, you should definitely check out
the tutorial on the Internet at http://www.python.org/doc/tut/.

Enter the name of any module, keyword, or topic to get help on writing
Python programs and using Python modules.  To quit this help utility and
return to the interpreter, just type "quit".

To get a list of available modules, keywords, or topics, type "modules",
"keywords", or "topics".  Each module also comes with a one-line summary
of what it does; to list the modules whose summaries contain a given word
such as "spam", type "modules spam".

help>

---
Patrick K. O'Brien
Orbtech
"I am, therefore I think."

-----Original Message-----
From: guido@odiug.digicool.com [mailto:guido@odiug.digicool.com]On Behalf Of
Guido van Rossum
Sent: Tuesday, June 12, 2001 10:20 AM
To: pobrien@orbtech.com
Cc: Guido van Rossum; IDLE Developers List; ping@lfw.org; Python Edu SIG
Subject: Re: [Edu-sig] Re: [Idle-dev] Weird error when pydoc.help is added
to builtin from site.py

<snip>
See if this also breaks when you do this in IDLE:

  >>> import pydoc
  >>> pydoc.help()

That eliminates the manipulation with __builtin__ as the cause of the
problem.  Then you'll have to step through the code or use pdb.pm() to
find out what was wrong...

--Guido van Rossum (home page: http://www.python.org/~guido/)



From guido@digicool.com  Tue Jun 12 17:21:27 2001
From: guido@digicool.com (Guido van Rossum)
Date: Tue, 12 Jun 2001 12:21:27 -0400
Subject: [Edu-sig] Re: [Idle-dev] Weird error when pydoc.help is added to builtin from site.py
In-Reply-To: Your message of "Tue, 12 Jun 2001 10:46:34 CDT."
 <NBBBIOJPGKJEKIECEMCBMEFHKAAA.pobrien@orbtech.com>
References: <NBBBIOJPGKJEKIECEMCBMEFHKAAA.pobrien@orbtech.com>
Message-ID: <200106121621.f5CGLRt25590@odiug.digicool.com>

> Import pydoc; pydoc.help definitely works. In fact, adding help to the
> builtins works from my PYTHONSTARTUP file or interactively, but not from
> site.py. That's what made it so weird, at least to me. But getting it loaded
> as part of site was our goal. I'll step through the code when I get a spare
> hour (or two or three <g>).
> 
> >>> import __builtin__
> >>> from pydoc import help
> >>> __builtin__.help = help
> >>> del help
> >>> del __builtin__
> >>> help
> 
> Welcome to Python 2.1!  This is the online help utility.
> 
> If this is your first time using Python, you should definitely check out
> the tutorial on the Internet at http://www.python.org/doc/tut/.
> 
> Enter the name of any module, keyword, or topic to get help on writing
> Python programs and using Python modules.  To quit this help utility and
> return to the interpreter, just type "quit".
> 
> To get a list of available modules, keywords, or topics, type "modules",
> "keywords", or "topics".  Each module also comes with a one-line summary
> of what it does; to list the modules whose summaries contain a given word
> such as "spam", type "modules spam".
> 
> help>

Thanks, that helps!  I think I've nailed your problem now.

The problem is that you are importing pydoc in site.py.  The site
module is imported by Python before IDLE has created its windows.
This means that sys.stdin and sys.stdout still point to the default
stdin and stdout of the process -- which don't really exist, since
IDLE doesn't run in a DOS box.  (I predict that if you run IDLE in a
DOS box, help() will "work" using the DOS box for its input and
output.)

One solution would be to fix pydoc so that it doesn't "freeze" the
values of sys.stdin and sys.stdout at the time it is imported.

But a better solution (I think) is to add this to site.py:

  class _Helper:
      def __repr__(self):
          return "Please type help() for interactive help."
      def __call__(self, *args, **kwds):
          import pydoc
          return pydoc.help(*args, *kwds)

  help = _helper()

This means that you have to type 'help()' instead of 'help' to get
help, but it avoids a whole bunch of other issues with the help object
as well, and it is consistent with the behavior of 'quit', 'exit' and
(especially) 'license'.  Note that 'license' faces a similar problem
and uses the same solution (the repr() message reminds the user of the
proper way to invoke it).

I find this much cooler than the hack that Ping proposed. :-)

--Guido van Rossum (home page: http://www.python.org/~guido/)


From cheselka@theriver.com  Tue Jun 12 17:30:46 2001
From: cheselka@theriver.com (Matthew Cheselka)
Date: Tue, 12 Jun 2001 09:30:46 -0700
Subject: [Idle-dev] idle, python, and swig
Message-ID: <3B2643B5.E8CC2320@theriver.com>

Good morning,

Guido's suggestion that I update to python 2.1 did the trick as far as
the problem I was encountering with IDLE.

So now I'm to the point where I'm wanting to migrate some work I've done
in the Linux realm over to the Windows NT realm.  I'm primarily using
python as a GUI in this sense and doing all of my other more
data-processing intensive functions in C, compiled with SWIG, and then
imported into python and used in the usual way.

So I can now import my SWIG-generation stuff from within the python
code:

    import imgtrack

but when the python code calls a method from within 'imgtrack':

    imgtrack.get_img (....)

I get this error on the IDLE command line:

Exception in Tkinter callback
Traceback (most recent call last):
  File "c:\python21\lib\lib-tk\Tkinter.py", line 1285, in __call__
    return apply(self.func, args)
  File "C:\Python21\imgtrack\imgtrack.py", line 29, in get_img
    imgtrack.get_img (imgptr, IMG_HORZ, IMG_VERT)
AttributeError: 'imgtrack' module has no attribute 'get_img'

Does anyone have any suggestions?  I realize that this isn't exactly an
IDLE problem, but it does have to do with me undertanding how python
within windows interacts with home-made imported modules.

Thanks and Cheers,

Matt Cheselka



From guido@digicool.com  Tue Jun 12 17:35:41 2001
From: guido@digicool.com (Guido van Rossum)
Date: Tue, 12 Jun 2001 12:35:41 -0400
Subject: [Edu-sig] Re: [Idle-dev] Weird error when pydoc.help is added to builtin from site.py
In-Reply-To: Your message of "Tue, 12 Jun 2001 12:21:27 EDT."
 <200106121621.f5CGLRt25590@odiug.digicool.com>
References: <NBBBIOJPGKJEKIECEMCBMEFHKAAA.pobrien@orbtech.com>
 <200106121621.f5CGLRt25590@odiug.digicool.com>
Message-ID: <200106121635.f5CGZku25682@odiug.digicool.com>

> But a better solution (I think) is to add this to site.py:
> 
>   class _Helper:
>       def __repr__(self):
>           return "Please type help() for interactive help."
>       def __call__(self, *args, **kwds):
>           import pydoc
>           return pydoc.help(*args, **kwds)
> 
>   help = _helper()

Sorry, there are some typos in it, and the message could be
friendlier.  How about this (insert after the assignment to
__builtin__.license in site.py):


# Define new built-in 'help'.
# This is a wrapper around pydoc.help (with a twist).

class _Helper:
    def __repr__(self):
        return "Type help() for interactive help, " \
               "or help(object) for help about object."
    def __call__(self, *args, **kwds):
        import pydoc
        return pydoc.help(*args, **kwds)

__builtin__.help = _Helper()


--Guido van Rossum (home page: http://www.python.org/~guido/)


From pobrien@orbtech.com  Tue Jun 12 17:55:14 2001
From: pobrien@orbtech.com (Patrick K. O'Brien)
Date: Tue, 12 Jun 2001 11:55:14 -0500
Subject: [Edu-sig] Re: [Idle-dev] Weird error when pydoc.help is added to builtin from site.py
In-Reply-To: <200106121635.f5CGZku25682@odiug.digicool.com>
Message-ID: <NBBBIOJPGKJEKIECEMCBOEFLKAAA.pobrien@orbtech.com>

Way cool. Thank you, Guido, for lending the help we needed. (No pun
intended, I swear.) I still remember the first time I ran python and typed
'help' at the prompt. Yikes! <grin> But not anymore. Now I'll get a friendly
response. I feel very good about this. Made it worth all the effort, and I
learned a thing or two. Time for a nap.

---
Patrick K. O'Brien
Orbtech
"I am, therefore I think."

-----Original Message-----
From: guido@odiug.digicool.com [mailto:guido@odiug.digicool.com]On Behalf Of
Guido van Rossum
Sent: Tuesday, June 12, 2001 11:36 AM
To: Guido van Rossum
Cc: pobrien@orbtech.com; IDLE Developers List; ping@lfw.org; Python Edu SIG
Subject: Re: [Edu-sig] Re: [Idle-dev] Weird error when pydoc.help is added
to builtin from site.py

> But a better solution (I think) is to add this to site.py:
>
>   class _Helper:
>       def __repr__(self):
>           return "Please type help() for interactive help."
>       def __call__(self, *args, **kwds):
>           import pydoc
>           return pydoc.help(*args, **kwds)
>
>   help = _helper()

Sorry, there are some typos in it, and the message could be
friendlier.  How about this (insert after the assignment to
__builtin__.license in site.py):


# Define new built-in 'help'.
# This is a wrapper around pydoc.help (with a twist).

class _Helper:
    def __repr__(self):
        return "Type help() for interactive help, " \
               "or help(object) for help about object."
    def __call__(self, *args, **kwds):
        import pydoc
        return pydoc.help(*args, **kwds)

__builtin__.help = _Helper()


--Guido van Rossum (home page: http://www.python.org/~guido/)



From wesc@deirdre.org  Tue Jun 19 01:10:43 2001
From: wesc@deirdre.org (Wesley Chun)
Date: Mon, 18 Jun 2001 17:10:43 -0700 (PDT)
Subject: [Idle-dev] IDLE's save-before-run requirement
In-Reply-To: <E15C9Ab-00048S-00@mail.python.org>
Message-ID: <Pine.LNX.4.31.0106181704000.12659-100000@emperor.deirdre.org>

the subject of this message is basically to get some feedback on
having to save a script within IDLE before running it.  when i'm
making a good number of small changes to my file, doing separate
sets of keystrokes started to get old, so i hacked together a
small patch that allows you to "save-n-run."

i thought i'd get Guido's opinion b4submitting a PEP.  he suggested
i also get some more comments from here.  below is basically what i
proposed and his response.

please direct any comments to me (and/or the group).  thanks!

-wesley

> >    b4 i waste people's time by filing a PEP on IDLE,
> >    have you had any comments regarding having to save
> >    a file before being able to run it?  i find myself
> >    having to do multiple sets of keystrokes every time
> >    i make a small edit, so i just hacked up a new key
> >    binding that does a save-n-run (Shift-F5).  i fi-
> >    gure, if it's not a good idea, at least it would be
> >    a good exercise in the Tkinter chapter!  :-)
> >
> >    any thoughts?  anyway, here's a quick 1-line diff:
> >
> > ScriptBinding.py:
> >
> > 16a17,19
> > > - Save and Run module (Shift-F5) does the same but saves *and*
> > > executes the module's code in the __main__ namespace.
> > >
> > 41a45
> > >         '<<save-and-run-script>>': ['<Shift-F5>'],
> > 48a53
> > >                   ('Save & Run script', '<<save-and-run-script>>'),
> > 150a156,166
> > >     def save_and_run_script_event(self, event):
> > >         if not self.editwin.get_saved():
> > >             name = (self.editwin.short_title() or
> > >                     self.editwin.long_title() or
> > >                     "Untitled")
> > >           if name == 'Untitled':
> > >               self.editwin.io.save_as(event)
> > >           else:
> > >               self.editwin.io.save(event)
> > >       self.run_script_event(event)
>
> Nice patch.
>
> The problem is that IDLE development has virtually come to a halt -- I
> just can't find the time to work on it, and there are other good
> development environments available.  I have some ideas for reworking
> the whole save/run machinery, but no code; and I have working code
> that runs the program in a subprocess, but there's a security issue
> that makes me hesitant to check it in...
>
> I wouldn't create a PEP for IDLE -- just discuss your ideas on
> idle-sig.  Maybe enough people are interested to get me coding
> again, or to get someone else to volunteer...
>
> --Guido van Rossum (home page: http://www.python.org/~guido/)



From mats@laplaza.org  Tue Jun 19 03:29:07 2001
From: mats@laplaza.org (Mats Wichmann)
Date: Mon, 18 Jun 2001 20:29:07 -0600
Subject: [Idle-dev] IDLE's save-before-run requirement
In-Reply-To: <Pine.LNX.4.31.0106181704000.12659-100000@emperor.deirdre.o
 rg>
References: <E15C9Ab-00048S-00@mail.python.org>
Message-ID: <5.1.0.14.1.20010618201428.01d484f0@laplaza.org>

At 05:10 PM 6/18/2001 -0700, Wesley Chun wrote:
 >the subject of this message is basically to get some feedback on
 >having to save a script within IDLE before running it.  when i'm
 >making a good number of small changes to my file, doing separate
 >sets of keystrokes started to get old, so i hacked together a
 >small patch that allows you to "save-n-run."
 >
 >i thought i'd get Guido's opinion b4submitting a PEP.  he suggested
 >i also get some more comments from here.  below is basically what i
 >proposed and his response.
 >
 >please direct any comments to me (and/or the group).  thanks!


As Guido knows, I'm certainly interested in IDLE evolving,
because I find it a very handy learning tool - not just
for me; like Wesley, I try to teach some Python classes
from time to time.  There may be "better" IDEs but I'm
not convinced I've seen one yet (for Python).  And in my
particular situation, it HAS to be cross-platform, I'm
not going to fuss with two different IDEs in a classroom
situation (students get to choose Win2k or Linux).

But I suspect most "serious programmers" don't really see
IDLE as being a "serious IDE" - at least I gather this
impression from comments on c.l.p, esp. from folks who come
from other (inferior?) languages where an IDE is essential to
maintaining any sanity, so they've evolved into quite sophisticated
tools. So I don't know if there'd be a whole lot of overall
enthusiam for doing a lot to IDLE.


Guido writes:

 >I have working code
 > that runs the program in a subprocess, but there's a security
 > issue that makes me hesitant to check it in...

Maybe we can at least hash this one out here and come up
with a workable solution.  I've had my eye on this since
I first heard about it, as a possible way to make IDLE
play with Jython - since the same process would not be
running the IDE/editor/etc. AND running the code you
develop, the subprocess could actually be Jython instead
of CPython.  Maybe. I hope. The description I got from
Guido didn't lead me to a brilliant solution to the
security concern, unfortunately.


Mats



From tony@lsl.co.uk  Tue Jun 19 10:45:56 2001
From: tony@lsl.co.uk (Tony J Ibbs (Tibs))
Date: Tue, 19 Jun 2001 10:45:56 +0100
Subject: [Idle-dev] IDLE "deemphasised"? Please not so...
In-Reply-To: <5.1.0.14.1.20010618201428.01d484f0@laplaza.org>
Message-ID: <003a01c0f8a4$a3137420$f05aa8c0@lslp7o.int.lsl.co.uk>

In Wesley Chun's thread on amending IDLE, Guido said:
> The problem is that IDLE development has virtually come to a halt
> -- I just can't find the time to work on it, and there are other
> good development environments available.

Mats Wichmann then said:
> As Guido knows, I'm certainly interested in IDLE evolving,
> because I find it a very handy learning tool - not just
> for me; like Wesley, I try to teach some Python classes
> from time to time.  There may be "better" IDEs but I'm
> not convinced I've seen one yet (for Python).  And in my
> particular situation, it HAS to be cross-platform, I'm
> not going to fuss with two different IDEs in a classroom
> situation (students get to choose Win2k or Linux).
>
> But I suspect most "serious programmers" don't really see
> IDLE as being a "serious IDE" - at least I gather this
> impression from comments on c.l.p, esp. from folks who come
> from other (inferior?) languages where an IDE is essential to
> maintaining any sanity, so they've evolved into quite sophisticated
> tools. So I don't know if there'd be a whole lot of overall
> enthusiam for doing a lot to IDLE.

Whilst I understand all about not having time for things because there
are other things to do (!), I do think it would be a pity if IDLE died
away. It seems to me there is a serious place for a moderately decent
editor that comes free with the Python disttribution, knows *about*
Python, and uses Tkinter (i.e., is maximally portable).

Whilst there might be *better* IDEs (in various senses of the word -
heck, I use XEmacs for "normal" work, does that count?), there is
*great* utility in having a reasonable editor that undestands Python up
and running as soon as one has Python up and running (e.g., on Windows).
After all, the alternative may well be Wordpad/Notepad.

Other IDEs involve other work (to set up), or even money. And for some
of us, each program coming in has to be paper-justified, so it may well
not be worth the effort anyway, even for free code.

If it helps, I'm satisfied with having an editor that understands Python
layout, and provides some debugging and class browsing support - if that
isn't a "proper" IDE I don't care (and I think I'm a moderately serious
programmer - it's been what I get paid for for a while now).

What do I actually want? Well, given Guido and co aren't going to do
much with IDLE in the future, I'd vote to at least keep it around, and
mention it as existing, and I'd hope that it might grow slowly via
sourceforge. Just don't underestimate the demand for it.

Tibs

--
Tony J Ibbs (Tibs)      http://www.tibsnjoan.co.uk/
"How fleeting are all human passions compared with the massive
continuity of ducks." - Dorothy L. Sayers, "Gaudy Night"
My views! Mine! Mine! (Unless Laser-Scan ask nicely to borrow them.)



From kbk@shore.net  Tue Jun 19 17:47:23 2001
From: kbk@shore.net (Kurt B. Kaiser)
Date: 19 Jun 2001 12:47:23 -0400
Subject: [Idle-dev] IDLE's save-before-run requirement
In-Reply-To: <Pine.LNX.4.31.0106181704000.12659-100000@emperor.deirdre.org>
References: <Pine.LNX.4.31.0106181704000.12659-100000@emperor.deirdre.org>
Message-ID: <m38zioben8.fsf@float.ne.mediaone.com>

Wesley Chun <wesc@deirdre.org> writes:

GvR wrote  to WChun:
> > The problem is that IDLE development has virtually come to a halt -- I
> > just can't find the time to work on it, and there are other good
> > development environments available.  I have some ideas for reworking
> > the whole save/run machinery, but no code; and I have working code
> > that runs the program in a subprocess, but there's a security issue
> > that makes me hesitant to check it in...
> >
> > I wouldn't create a PEP for IDLE -- just discuss your ideas on
> > idle-sig.  Maybe enough people are interested to get me coding
> > again, or to get someone else to volunteer...

It's great to see some activity on the list again, it almost died out the last
few months!

I agree with the others; IDLE is a very useful IDE for Python which has a
unique set of features compared to other solutions:

1. Open souce
2. Under ultimate control of GvR.
3. Portable via Tkinter.
4. Very usable by relatively inexperienced people.
5. Has a Python debugger.
6. Understands Python syntax and environment.
7. Provides an extended example of Python programming.
8. Distributed with all versions of Python at very reasonable cost,
   so available to first time, casual, or resource limited users.

I'm sure the others on this list can think of further advantages!

IMHO IDLE should remain at roughly the (apparent) level of complexity it's at
(or less?) to avoid reducing its usability for beginning/intermediate
programmers.  And there are some things which can be done to further improve
usability and reliability, IMHO, like running the target code in a separate
process.

I hope we can encourage Guido to continue to share his IDLE thoughts ( ;-)
with us, either via code or design direction!

Regards, KBK


From mail@peterbe.com  Wed Jun 20 09:35:25 2001
From: mail@peterbe.com (Peter Bengtsson)
Date: Wed, 20 Jun 2001 10:35:25 +0200
Subject: [Idle-dev] IDLE's save-before-run requirement
References: <Pine.LNX.4.31.0106181704000.12659-100000@emperor.deirdre.org> <m38zioben8.fsf@float.ne.mediaone.com>
Message-ID: <003a01c0f964$804400c0$1c64a8c0@PBN>

Let me add the Zen I have with IDLE in Windows with the 0.5 version!
Great work!
I feel very comfortable with it and everything looks nice and is getting
very stable.
The Alt+F2 is wicked! I use it a lot and I love having 10 little windows
open all the time.

It's just like Notepad in Windows. Keep it simple ... [no need to say more]

Now, if somebody can tell me just to unamericanize the shortkeys, then I
would be very happy.

Peter


----- Original Message -----
From: "Kurt B. Kaiser" <kbk@shore.net>
To: <idle-dev@python.org>
Sent: Tuesday, June 19, 2001 6:47 PM
Subject: Re: [Idle-dev] IDLE's save-before-run requirement


> Wesley Chun <wesc@deirdre.org> writes:
>
> GvR wrote  to WChun:
> > > The problem is that IDLE development has virtually come to a halt -- I
> > > just can't find the time to work on it, and there are other good
> > > development environments available.  I have some ideas for reworking
> > > the whole save/run machinery, but no code; and I have working code
> > > that runs the program in a subprocess, but there's a security issue
> > > that makes me hesitant to check it in...
> > >
> > > I wouldn't create a PEP for IDLE -- just discuss your ideas on
> > > idle-sig.  Maybe enough people are interested to get me coding
> > > again, or to get someone else to volunteer...
>
> It's great to see some activity on the list again, it almost died out the
last
> few months!
>
> I agree with the others; IDLE is a very useful IDE for Python which has a
> unique set of features compared to other solutions:
>
> 1. Open souce
> 2. Under ultimate control of GvR.
> 3. Portable via Tkinter.
> 4. Very usable by relatively inexperienced people.
> 5. Has a Python debugger.
> 6. Understands Python syntax and environment.
> 7. Provides an extended example of Python programming.
> 8. Distributed with all versions of Python at very reasonable cost,
>    so available to first time, casual, or resource limited users.
>
> I'm sure the others on this list can think of further advantages!
>
> IMHO IDLE should remain at roughly the (apparent) level of complexity it's
at
> (or less?) to avoid reducing its usability for beginning/intermediate
> programmers.  And there are some things which can be done to further
improve
> usability and reliability, IMHO, like running the target code in a
separate
> process.
>
> I hope we can encourage Guido to continue to share his IDLE thoughts ( ;-)
> with us, either via code or design direction!
>
> Regards, KBK
>
> _______________________________________________
> IDLE-dev mailing list
> IDLE-dev@python.org
> http://mail.python.org/mailman/listinfo/idle-dev



From pobrien@orbtech.com  Wed Jun 20 16:57:51 2001
From: pobrien@orbtech.com (Patrick K. O'Brien)
Date: Wed, 20 Jun 2001 10:57:51 -0500
Subject: [Idle-dev] IDLE "deemphasised"? Please not so...
In-Reply-To: <003a01c0f8a4$a3137420$f05aa8c0@lslp7o.int.lsl.co.uk>
Message-ID: <NBBBIOJPGKJEKIECEMCBEEABKBAA.pobrien@orbtech.com>

I agree with these sentiments and am copying this message to the Edu and
Tutor lists because I think the folks there are a good part of the demand
that you mention below.

---
Patrick K. O'Brien
Orbtech
"I am, therefore I think."

-----Original Message-----
From: idle-dev-admin@python.org [mailto:idle-dev-admin@python.org]On Behalf
Of Tony J Ibbs (Tibs)
Sent: Tuesday, June 19, 2001 4:46 AM
To: idle-dev@python.org
Subject: [Idle-dev] IDLE "deemphasised"? Please not so...

In Wesley Chun's thread on amending IDLE, Guido said:
> The problem is that IDLE development has virtually come to a halt
> -- I just can't find the time to work on it, and there are other
> good development environments available.

Mats Wichmann then said:
> As Guido knows, I'm certainly interested in IDLE evolving,
> because I find it a very handy learning tool - not just
> for me; like Wesley, I try to teach some Python classes
> from time to time.  There may be "better" IDEs but I'm
> not convinced I've seen one yet (for Python).  And in my
> particular situation, it HAS to be cross-platform, I'm
> not going to fuss with two different IDEs in a classroom
> situation (students get to choose Win2k or Linux).
>
> But I suspect most "serious programmers" don't really see
> IDLE as being a "serious IDE" - at least I gather this
> impression from comments on c.l.p, esp. from folks who come
> from other (inferior?) languages where an IDE is essential to
> maintaining any sanity, so they've evolved into quite sophisticated
> tools. So I don't know if there'd be a whole lot of overall
> enthusiam for doing a lot to IDLE.

Whilst I understand all about not having time for things because there
are other things to do (!), I do think it would be a pity if IDLE died
away. It seems to me there is a serious place for a moderately decent
editor that comes free with the Python disttribution, knows *about*
Python, and uses Tkinter (i.e., is maximally portable).

Whilst there might be *better* IDEs (in various senses of the word -
heck, I use XEmacs for "normal" work, does that count?), there is
*great* utility in having a reasonable editor that undestands Python up
and running as soon as one has Python up and running (e.g., on Windows).
After all, the alternative may well be Wordpad/Notepad.

Other IDEs involve other work (to set up), or even money. And for some
of us, each program coming in has to be paper-justified, so it may well
not be worth the effort anyway, even for free code.

If it helps, I'm satisfied with having an editor that understands Python
layout, and provides some debugging and class browsing support - if that
isn't a "proper" IDE I don't care (and I think I'm a moderately serious
programmer - it's been what I get paid for for a while now).

What do I actually want? Well, given Guido and co aren't going to do
much with IDLE in the future, I'd vote to at least keep it around, and
mention it as existing, and I'd hope that it might grow slowly via
sourceforge. Just don't underestimate the demand for it.

Tibs

--
Tony J Ibbs (Tibs)      http://www.tibsnjoan.co.uk/
"How fleeting are all human passions compared with the massive
continuity of ducks." - Dorothy L. Sayers, "Gaudy Night"
My views! Mine! Mine! (Unless Laser-Scan ask nicely to borrow them.)


_______________________________________________
IDLE-dev mailing list
IDLE-dev@python.org
http://mail.python.org/mailman/listinfo/idle-dev



From pobrien@orbtech.com  Wed Jun 20 16:55:12 2001
From: pobrien@orbtech.com (Patrick K. O'Brien)
Date: Wed, 20 Jun 2001 10:55:12 -0500
Subject: [Idle-dev] IDLE's save-before-run requirement
In-Reply-To: <Pine.LNX.4.31.0106181704000.12659-100000@emperor.deirdre.org>
Message-ID: <NBBBIOJPGKJEKIECEMCBAEABKBAA.pobrien@orbtech.com>

I can't give a whole lot of feedback except to say that I'd hate to see IDLE
abandoned. Maybe there needs to be an effort to get more people involved in
its upkeep. I'm copying this reply to the Edu and Tutor lists, because IDLE
comes up in conversations over there quite a bit. I think there might be
enough interest to motivate some folks. We certainly had things going when
we figured out how to get Python to respond to "help" in interactive
sessions. Maybe we could come up with a way to keep development of IDLE
moving along without the entire burden falling on Guido.

---
Patrick K. O'Brien
Orbtech
"I am, therefore I think."

-----Original Message-----
From: idle-dev-admin@python.org [mailto:idle-dev-admin@python.org]On Behalf
Of Wesley Chun
Sent: Monday, June 18, 2001 7:11 PM
To: idle-dev@python.org
Subject: [Idle-dev] IDLE's save-before-run requirement

the subject of this message is basically to get some feedback on
having to save a script within IDLE before running it.  when i'm
making a good number of small changes to my file, doing separate
sets of keystrokes started to get old, so i hacked together a
small patch that allows you to "save-n-run."

i thought i'd get Guido's opinion b4submitting a PEP.  he suggested
i also get some more comments from here.  below is basically what i
proposed and his response.

please direct any comments to me (and/or the group).  thanks!

-wesley

> >    b4 i waste people's time by filing a PEP on IDLE,
> >    have you had any comments regarding having to save
> >    a file before being able to run it?  i find myself
> >    having to do multiple sets of keystrokes every time
> >    i make a small edit, so i just hacked up a new key
> >    binding that does a save-n-run (Shift-F5).  i fi-
> >    gure, if it's not a good idea, at least it would be
> >    a good exercise in the Tkinter chapter!  :-)
> >
> >    any thoughts?  anyway, here's a quick 1-line diff:
> >
> > ScriptBinding.py:
> >
> > 16a17,19
> > > - Save and Run module (Shift-F5) does the same but saves *and*
> > > executes the module's code in the __main__ namespace.
> > >
> > 41a45
> > >         '<<save-and-run-script>>': ['<Shift-F5>'],
> > 48a53
> > >                   ('Save & Run script', '<<save-and-run-script>>'),
> > 150a156,166
> > >     def save_and_run_script_event(self, event):
> > >         if not self.editwin.get_saved():
> > >             name = (self.editwin.short_title() or
> > >                     self.editwin.long_title() or
> > >                     "Untitled")
> > >           if name == 'Untitled':
> > >               self.editwin.io.save_as(event)
> > >           else:
> > >               self.editwin.io.save(event)
> > >       self.run_script_event(event)
>
> Nice patch.
>
> The problem is that IDLE development has virtually come to a halt -- I
> just can't find the time to work on it, and there are other good
> development environments available.  I have some ideas for reworking
> the whole save/run machinery, but no code; and I have working code
> that runs the program in a subprocess, but there's a security issue
> that makes me hesitant to check it in...
>
> I wouldn't create a PEP for IDLE -- just discuss your ideas on
> idle-sig.  Maybe enough people are interested to get me coding
> again, or to get someone else to volunteer...
>
> --Guido van Rossum (home page: http://www.python.org/~guido/)


_______________________________________________
IDLE-dev mailing list
IDLE-dev@python.org
http://mail.python.org/mailman/listinfo/idle-dev



From delza@alliances.org  Wed Jun 20 17:23:21 2001
From: delza@alliances.org (Dethe Elza)
Date: Wed, 20 Jun 2001 09:23:21 -0700
Subject: [Edu-sig] RE: [Idle-dev] IDLE "deemphasised"? Please not so...
In-Reply-To: <NBBBIOJPGKJEKIECEMCBEEABKBAA.pobrien@orbtech.com>
Message-ID: <B7561C09.CD9%delza@alliances.org>

It seems to me that the VPython folk are the perfect ones to pick up the
IDLE development reins.  They're actively working on IDLE already, have
already implemented the autosave mentioned, as well as some others, and
generally seem willing and interested.  I'm not sure what the reasoning is
for keeping the VPython IDLE off in its own fork and not bringing it in as
the official IDLE, since it is being actively developed.

--Dethe

on 01/6/20 08:57 AM, Patrick K. O'Brien at pobrien@orbtech.com wrote:

> I agree with these sentiments and am copying this message to the Edu and
> Tutor lists because I think the folks there are a good part of the demand
> that you mention below.
> 
> In Wesley Chun's thread on amending IDLE, Guido said:
>> The problem is that IDLE development has virtually come to a halt
>> -- I just can't find the time to work on it, and there are other
>> good development environments available.
> 
> Mats Wichmann then said:
>> As Guido knows, I'm certainly interested in IDLE evolving,
>> because I find it a very handy learning tool - not just
>> for me; like Wesley, I try to teach some Python classes
>> from time to time.  There may be "better" IDEs but I'm
>> not convinced I've seen one yet (for Python).  And in my
>> particular situation, it HAS to be cross-platform, I'm
>> not going to fuss with two different IDEs in a classroom
>> situation (students get to choose Win2k or Linux).
>> 
>> But I suspect most "serious programmers" don't really see
>> IDLE as being a "serious IDE" - at least I gather this
>> impression from comments on c.l.p, esp. from folks who come
>> from other (inferior?) languages where an IDE is essential to
>> maintaining any sanity, so they've evolved into quite sophisticated
>> tools. So I don't know if there'd be a whole lot of overall
>> enthusiam for doing a lot to IDLE.
> 
> Whilst I understand all about not having time for things because there
> are other things to do (!), I do think it would be a pity if IDLE died
> away. It seems to me there is a serious place for a moderately decent
> editor that comes free with the Python disttribution, knows *about*
> Python, and uses Tkinter (i.e., is maximally portable).
> 
> Whilst there might be *better* IDEs (in various senses of the word -
> heck, I use XEmacs for "normal" work, does that count?), there is
> *great* utility in having a reasonable editor that undestands Python up
> and running as soon as one has Python up and running (e.g., on Windows).
> After all, the alternative may well be Wordpad/Notepad.
> 
> Other IDEs involve other work (to set up), or even money. And for some
> of us, each program coming in has to be paper-justified, so it may well
> not be worth the effort anyway, even for free code.
> 
> If it helps, I'm satisfied with having an editor that understands Python
> layout, and provides some debugging and class browsing support - if that
> isn't a "proper" IDE I don't care (and I think I'm a moderately serious
> programmer - it's been what I get paid for for a while now).
> 
> What do I actually want? Well, given Guido and co aren't going to do
> much with IDLE in the future, I'd vote to at least keep it around, and
> mention it as existing, and I'd hope that it might grow slowly via
> sourceforge. Just don't underestimate the demand for it.
> 
> Tibs

-- 

Dethe Elza 
Chief Mad Scientist
Burning Tiger Technologies




From pdx4d@teleport.com  Wed Jun 20 17:23:44 2001
From: pdx4d@teleport.com (Kirby Urner)
Date: Wed, 20 Jun 2001 09:23:44 -0700
Subject: [Edu-sig] RE: [Idle-dev] IDLE's save-before-run requirement
In-Reply-To: <NBBBIOJPGKJEKIECEMCBAEABKBAA.pobrien@orbtech.com>
References: <Pine.LNX.4.31.0106181704000.12659-100000@emperor.deirdre.org>
Message-ID: <4.2.0.58.20010620092102.00a39f00@pop3.norton.antivirus>

Lots of schools have iMacs and teaching Python would probably
involve using IDLE on a Mac.  I tried this once.  My recollection
is I didn't get the color-coding of key words.  Can anyone
confirm/disconfirm this is a missing feature in Mac version?
Perhaps I missed a toggle or something.

Kirby
Python IDLE user



From guido@digicool.com  Wed Jun 20 19:06:40 2001
From: guido@digicool.com (Guido van Rossum)
Date: Wed, 20 Jun 2001 14:06:40 -0400
Subject: [Edu-sig] RE: [Idle-dev] IDLE "deemphasised"? Please not so...
In-Reply-To: Your message of "Wed, 20 Jun 2001 09:23:21 PDT."
 <B7561C09.CD9%delza@alliances.org>
References: <B7561C09.CD9%delza@alliances.org>
Message-ID: <200106201806.f5KI6eN01330@odiug.digicool.com>

> It seems to me that the VPython folk are the perfect ones to pick up the
> IDLE development reins.  They're actively working on IDLE already, have
> already implemented the autosave mentioned, as well as some others, and
> generally seem willing and interested.  I'm not sure what the reasoning is
> for keeping the VPython IDLE off in its own fork and not bringing it in as
> the official IDLE, since it is being actively developed.

I think it was that I wanted to keep control over the direction in
which IDLE was going.  The idle-fork SourceForge project was created
so they could do their development.  But I don't think much happened
there, and I haven't really done much except stifle IDLE development,
so I'm ready to relax my control.  I do have that subprocess-running
code which I would like to get worked into IDLE first though...

--Guido van Rossum (home page: http://www.python.org/~guido/)



From guido@digicool.com  Wed Jun 20 19:07:39 2001
From: guido@digicool.com (Guido van Rossum)
Date: Wed, 20 Jun 2001 14:07:39 -0400
Subject: [Edu-sig] RE: [Idle-dev] IDLE's save-before-run requirement
In-Reply-To: Your message of "Wed, 20 Jun 2001 09:23:44 PDT."
 <4.2.0.58.20010620092102.00a39f00@pop3.norton.antivirus>
References: <Pine.LNX.4.31.0106181704000.12659-100000@emperor.deirdre.org>
 <4.2.0.58.20010620092102.00a39f00@pop3.norton.antivirus>
Message-ID: <200106201807.f5KI7dL01340@odiug.digicool.com>

> Lots of schools have iMacs and teaching Python would probably
> involve using IDLE on a Mac.  I tried this once.  My recollection
> is I didn't get the color-coding of key words.  Can anyone
> confirm/disconfirm this is a missing feature in Mac version?
> Perhaps I missed a toggle or something.
> 
> Kirby
> Python IDLE user

Actually, IDLE on a Mac doesn't really work, because Tcl on a Mac
doesn't really work.

But MacPython comes with its own IDE, built by Just van Rossum (my
brother) using the native Mac toolbox.

--Guido van Rossum (home page: http://www.python.org/~guido/)


From israel@lith.com  Wed Jun 20 19:16:23 2001
From: israel@lith.com (Israel Evans)
Date: Wed, 20 Jun 2001 11:16:23 -0700
Subject: [Tutor] Re: [Edu-sig] RE: [Idle-dev] IDLE's save-before-run r
 equirement
Message-ID: <AF020C5FC551DD43A4958A679EA16A15A144D9@mailcluster.lith.com>

I'd just like to say that I love IDLE.  It's the only thing I do Python in.
It's also the First tool that has made me comfortable with an interactive
interpreter.  Emacs just frightens me! Vim is Spooky! IDLE is just right!

~Israel~

-----Original Message-----
From: Guido van Rossum [mailto:guido@digicool.com]
Sent: Wednesday, June 20, 2001 11:08 AM
To: Kirby Urner
Cc: pobrien@orbtech.com; idle-dev@python.org; Python Edu SIG; Python
Tutor
Subject: [Tutor] Re: [Edu-sig] RE: [Idle-dev] IDLE's save-before-run
requirement


> Lots of schools have iMacs and teaching Python would probably
> involve using IDLE on a Mac.  I tried this once.  My recollection
> is I didn't get the color-coding of key words.  Can anyone
> confirm/disconfirm this is a missing feature in Mac version?
> Perhaps I missed a toggle or something.
> 
> Kirby
> Python IDLE user

Actually, IDLE on a Mac doesn't really work, because Tcl on a Mac
doesn't really work.

But MacPython comes with its own IDE, built by Just van Rossum (my
brother) using the native Mac toolbox.

--Guido van Rossum (home page: http://www.python.org/~guido/)

_______________________________________________
Tutor maillist  -  Tutor@python.org
http://mail.python.org/mailman/listinfo/tutor


From deirdre@deirdre.net  Wed Jun 20 19:16:02 2001
From: deirdre@deirdre.net (Deirdre Saoirse Moen)
Date: Wed, 20 Jun 2001 11:16:02 -0700
Subject: [Tutor] Re: [Edu-sig] RE: [Idle-dev] IDLE's save-before-run
 requirement
In-Reply-To: <200106201807.f5KI7dL01340@odiug.digicool.com>
References: <Pine.LNX.4.31.0106181704000.12659-100000@emperor.deirdre.org>
 <4.2.0.58.20010620092102.00a39f00@pop3.norton.antivirus>
 <200106201807.f5KI7dL01340@odiug.digicool.com>
Message-ID: <a05100e10b75697ec98ed@[169.254.218.155]>

At 2:07 PM -0400 6/20/01, Guido van Rossum wrote:
>  > Lots of schools have iMacs and teaching Python would probably
>>  involve using IDLE on a Mac.  I tried this once.  My recollection
>>  is I didn't get the color-coding of key words.  Can anyone
>>  confirm/disconfirm this is a missing feature in Mac version?
>>  Perhaps I missed a toggle or something.
>>
>>  Kirby
>>  Python IDLE user
>
>Actually, IDLE on a Mac doesn't really work, because Tcl on a Mac
>doesn't really work.
>
>But MacPython comes with its own IDE, built by Just van Rossum (my
>brother) using the native Mac toolbox.

And he's a great help to the Mac Python community.

As Russell E Owen also pointed out today on PythonMac:

"Christopher Stern wrote a nice BBEdit Python language plugin, available from
<http://homepage.mac.com/christopherstern/>. That is the only one I know of.

Also, just for the record, the Pepper editor has Python syntax 
coloring built in. I believe Alpha may, as well."

I don't know if the BBEdit plugin works on MacOS X; I haven't tried 
either yet. (I've been using TextEdit for python mostly because I've 
been to crushed with grad school work to bother downloading and 
installing stuff)
-- 
_Deirdre    Stash-o-Matic: http://weirdre.com    http://deirdre.net
"Cannot run out of time.... Is infinite time. You... are finite....
Zathrus... is finite. This... is wrong tool!" -- Zathrus


From pobrien@orbtech.com  Wed Jun 20 19:43:48 2001
From: pobrien@orbtech.com (Patrick K. O'Brien)
Date: Wed, 20 Jun 2001 13:43:48 -0500
Subject: [Tutor] Re: [Edu-sig] RE: [Idle-dev] IDLE's save-before-run requirement
In-Reply-To: <AF020C5FC551DD43A4958A679EA16A15A144D9@mailcluster.lith.com>
Message-ID: <NBBBIOJPGKJEKIECEMCBEEAMKBAA.pobrien@orbtech.com>

I agree with that sentiment. While I also use Boa, PythonWin and VPython, I
still like IDLE and usually pop it up for interactive use. What I really
want is the best of them all. I hate to see all these efforts recreating the
wheel. Of course, Boa and PythonWin both use Scintilla, although in slightly
different fashions. It might be nice if everyone standardized on Scintilla
for the core editing capabilities and spent the rest of their effort on
value-added stuff. (Though it wouldn't surprise me if Guido was reluctant to
go with that suggestion and I can't say I blame him.) I think everyone would
benefit if there was more code sharing and/or standard modules for the
standard features that any editor/IDE would have to have. And it would be
nice if these were GUI independent so that we could go from Tkinter to
wxWindows, for example, if we wanted to.

---
Patrick K. O'Brien
Orbtech
"I am, therefore I think."

-----Original Message-----
From: edu-sig-admin@python.org [mailto:edu-sig-admin@python.org]On Behalf Of
Israel Evans
Sent: Wednesday, June 20, 2001 1:16 PM
To: 'Guido van Rossum'; Kirby Urner
Cc: pobrien@orbtech.com; idle-dev@python.org; Python Edu SIG; Python Tutor
Subject: RE: [Tutor] Re: [Edu-sig] RE: [Idle-dev] IDLE's save-before-run
requirement

I'd just like to say that I love IDLE.  It's the only thing I do Python in.
It's also the First tool that has made me comfortable with an interactive
interpreter.  Emacs just frightens me! Vim is Spooky! IDLE is just right!

~Israel~




From deirdre@deirdre.net  Wed Jun 20 19:27:51 2001
From: deirdre@deirdre.net (Deirdre Saoirse Moen)
Date: Wed, 20 Jun 2001 11:27:51 -0700
Subject: [Tutor] Re: [Edu-sig] RE: [Idle-dev] IDLE's save-before-run r
 equirement
In-Reply-To: <AF020C5FC551DD43A4958A679EA16A15A144D9@mailcluster.lith.com>
References: <AF020C5FC551DD43A4958A679EA16A15A144D9@mailcluster.lith.com>
Message-ID: <a05100e12b7569ad9484a@[169.254.218.155]>

At 11:16 AM -0700 6/20/01, Israel Evans wrote:
>I'd just like to say that I love IDLE.  It's the only thing I do Python in.
>It's also the First tool that has made me comfortable with an interactive
>interpreter.  Emacs just frightens me! Vim is Spooky! IDLE is just right!

This really isn't on-topic, but it's one of my favorite stories, so 
bear with me. :)

My husband, Rick Moen, is an avid vi user. Once, when he was 
entertaining Richard Stallman (for those who may not know, the author 
of emacs), Rick teased RMS by saying, "I hope you don't mind sitting 
next to a vi user."

RMS responded, "we of the Church of emacs believe that use of vi is 
not a sin, but rather penance."

-- 
_Deirdre    Stash-o-Matic: http://weirdre.com    http://deirdre.net
"Cannot run out of time.... Is infinite time. You... are finite....
Zathrus... is finite. This... is wrong tool!" -- Zathrus


From mats@laplaza.org  Wed Jun 20 19:57:25 2001
From: mats@laplaza.org (Mats Wichmann)
Date: Wed, 20 Jun 2001 12:57:25 -0600
Subject: [Tutor] Re: [Edu-sig] RE: [Idle-dev] IDLE's
 save-before-run requirement
In-Reply-To: <NBBBIOJPGKJEKIECEMCBEEAMKBAA.pobrien@orbtech.com>
References: <AF020C5FC551DD43A4958A679EA16A15A144D9@mailcluster.lith.com>
Message-ID: <5.1.0.14.1.20010620125502.00ab55c8@laplaza.org>

 >And it would be
 >nice if these were GUI independent so that we could go from Tkinter to
 >wxWindows, for example, if we wanted to.

I once asked about something like this.  I believe right now
IDLE, at least, is not constructed in such a way that it
would be easy to rip out the Tkinter dependence so it could
be changed to something else, either permanently or for
plug-replacable graphics toolkits.

I wonder how much work that really would be, and if anybody
has any interest in it.  Not sure if there's really enough
value to be gained to make it worthwhile.

Mats



From guido@digicool.com  Wed Jun 20 20:24:48 2001
From: guido@digicool.com (Guido van Rossum)
Date: Wed, 20 Jun 2001 15:24:48 -0400
Subject: [Idle-dev] IDLE's save-before-run requirement
In-Reply-To: Your message of "Wed, 20 Jun 2001 12:57:25 MDT."
 <5.1.0.14.1.20010620125502.00ab55c8@laplaza.org>
References: <AF020C5FC551DD43A4958A679EA16A15A144D9@mailcluster.lith.com>
 <5.1.0.14.1.20010620125502.00ab55c8@laplaza.org>
Message-ID: <200106201924.f5KJOm901647@odiug.digicool.com>

> I once asked about something like this.  I believe right now
> IDLE, at least, is not constructed in such a way that it
> would be easy to rip out the Tkinter dependence so it could
> be changed to something else, either permanently or for
> plug-replacable graphics toolkits.
> 
> I wonder how much work that really would be, and if anybody
> has any interest in it.  Not sure if there's really enough
> value to be gained to make it worthwhile.
> 
> Mats

Well, once I check in my subprocess code, you will be able to use IDLE
to edit and run code using any GUI toolkit you have available.  (It
should also be possible to use Jython as the subprocess, although I'm
not going to enable that.)

Here's my dilemma.

I have a somewhat working "remote" mode, which executes commands in a
subprocess.  However, it's got a HUUUUUUGE security hole.  The
subprocess acts as a server, and the first client to connect to it
will get to execute arbitrary Python code in the subprocess.  It is
the intention that the IDLE main program is this client, but how can
we be sure?  Someone who knew you were starting IDLE could try to
hijack the subprocess and would then have all your permissions.  If
they tried enough times they would likely be successful.

The parent could pass some kind of random number to the subprocess,
but I know about this approach that unless you have a source of truly
random bits, it's relatively easy for the bad guy to guess the what
your pseudo-random number generator will come up with, and I just
don't want to release code with such a huge security problem.

I am begging for someone else to help me solve this problem.  Telling
me "just check it in" won't do -- I will not release code with a known
security hole.

The remote mode is a lot slower too, when there's a lot of output
being produced.  But I wouldn't mind releasing that. :-)

--Guido van Rossum (home page: http://www.python.org/~guido/)


From delza@alliances.org  Wed Jun 20 21:18:18 2001
From: delza@alliances.org (Dethe Elza)
Date: Wed, 20 Jun 2001 13:18:18 -0700
Subject: [Tutor] Re: [Edu-sig] RE: [Idle-dev] IDLE's save-before-run
 requirement
In-Reply-To: <NBBBIOJPGKJEKIECEMCBEEAMKBAA.pobrien@orbtech.com>
Message-ID: <B756531A.CFD%delza@alliances.org>

on 01/6/20 11:43 AM, Patrick K. O'Brien at pobrien@orbtech.com wrote:

> I agree with that sentiment. While I also use Boa, PythonWin and VPython, I
> still like IDLE and usually pop it up for interactive use. What I really
> want is the best of them all. I hate to see all these efforts recreating the
> wheel. Of course, Boa and PythonWin both use Scintilla, although in slightly
> different fashions.

And as far as I know, Scintilla hasn't been ported to the Mac, and possibly
other python-enabled platforms.

> It might be nice if everyone standardized on Scintilla
> for the core editing capabilities and spent the rest of their effort on
> value-added stuff. (Though it wouldn't surprise me if Guido was reluctant to
> go with that suggestion and I can't say I blame him.) I think everyone would
> benefit if there was more code sharing and/or standard modules for the
> standard features that any editor/IDE would have to have. And it would be
> nice if these were GUI independent so that we could go from Tkinter to
> wxWindows, for example, if we wanted to.

I think that's the goal of Parrot [1], although I'd prefer to see an
XML-based language for GUI construction with engines for various
languages/platforms/toolkits.  But that just isn't going to happen anytime
soon (although the UIML[2] and XForms[3] projects are working in that
direction).  Since every language and platform seems to be developing ways
to encode their GUI resources in XML, and since the capabilities of GUI
toolkits seem to be approaching a useful common subset, maybe there's hope
someday.

--Dethe

[1] http://www.vision25.demon.co.uk/oss/parrot/intro.html
[2] http://www.uiml.org/
[3] http://www.w3.org/MarkUp/Forms/

> 
> ---
> Patrick K. O'Brien
> Orbtech
> "I am, therefore I think."
> 
> -----Original Message-----
> From: edu-sig-admin@python.org [mailto:edu-sig-admin@python.org]On Behalf Of
> Israel Evans
> Sent: Wednesday, June 20, 2001 1:16 PM
> To: 'Guido van Rossum'; Kirby Urner
> Cc: pobrien@orbtech.com; idle-dev@python.org; Python Edu SIG; Python Tutor
> Subject: RE: [Tutor] Re: [Edu-sig] RE: [Idle-dev] IDLE's save-before-run
> requirement
> 
> I'd just like to say that I love IDLE.  It's the only thing I do Python in.
> It's also the First tool that has made me comfortable with an interactive
> interpreter.  Emacs just frightens me! Vim is Spooky! IDLE is just right!
> 
> ~Israel~
> 
> 
> 
> _______________________________________________
> Edu-sig mailing list
> Edu-sig@python.org
> http://mail.python.org/mailman/listinfo/edu-sig
> 

-- 

Dethe Elza 
Chief Mad Scientist
Burning Tiger Technologies




From delza@alliances.org  Wed Jun 20 21:20:04 2001
From: delza@alliances.org (Dethe Elza)
Date: Wed, 20 Jun 2001 13:20:04 -0700
Subject: [Edu-sig] RE: [Idle-dev] IDLE "deemphasised"? Please not so...
In-Reply-To: <200106201806.f5KI6eN01330@odiug.digicool.com>
Message-ID: <B7565384.CFE%delza@alliances.org>

That's great news!  Are the VPython folks listening?

--Dethe

on 01/6/20 11:06 AM, Guido van Rossum at guido@digicool.com wrote:

>> It seems to me that the VPython folk are the perfect ones to pick up the
>> IDLE development reins.  They're actively working on IDLE already, have
>> already implemented the autosave mentioned, as well as some others, and
>> generally seem willing and interested.  I'm not sure what the reasoning is
>> for keeping the VPython IDLE off in its own fork and not bringing it in as
>> the official IDLE, since it is being actively developed.
> 
> I think it was that I wanted to keep control over the direction in
> which IDLE was going.  The idle-fork SourceForge project was created
> so they could do their development.  But I don't think much happened
> there, and I haven't really done much except stifle IDLE development,
> so I'm ready to relax my control.  I do have that subprocess-running
> code which I would like to get worked into IDLE first though...
> 
> --Guido van Rossum (home page: http://www.python.org/~guido/)
> 
> 

-- 

Dethe Elza 
Chief Mad Scientist
Burning Tiger Technologies




From pobrien@orbtech.com  Wed Jun 20 22:21:11 2001
From: pobrien@orbtech.com (Patrick K. O'Brien)
Date: Wed, 20 Jun 2001 16:21:11 -0500
Subject: [Tutor] Re: [Edu-sig] RE: [Idle-dev] IDLE's save-before-runrequirement
In-Reply-To: <B756531A.CFD%delza@alliances.org>
Message-ID: <NBBBIOJPGKJEKIECEMCBEEBFKBAA.pobrien@orbtech.com>

Tkinter doesn't run on the Mac either, which means IDLE doesn't run on the
Mac (though, as Guido pointed out, there is an alternative). I'm not as
bothered by the fact that Scintilla isn't on the Mac as I am by the fact
that IDLE is intimately tied to Tkinter. Then again, I wonder how easy it
would be to "recreate" the same IDLE functionality with Scintilla. Since
Scintilla does so much cool text handling already, what else would have to
be added and how hard would it be to extract only the remaining pieces out
of IDLE? Wish I knew.

---
Patrick K. O'Brien
Orbtech
"I am, therefore I think."

-----Original Message-----
From: edu-sig-admin@python.org [mailto:edu-sig-admin@python.org]On Behalf Of
Dethe Elza
Sent: Wednesday, June 20, 2001 3:18 PM
To: idle-dev@python.org; Python Edu SIG; Python Tutor
Subject: Re: [Tutor] Re: [Edu-sig] RE: [Idle-dev] IDLE's
save-before-runrequirement

on 01/6/20 11:43 AM, Patrick K. O'Brien at pobrien@orbtech.com wrote:

> I agree with that sentiment. While I also use Boa, PythonWin and VPython,
I
> still like IDLE and usually pop it up for interactive use. What I really
> want is the best of them all. I hate to see all these efforts recreating
the
> wheel. Of course, Boa and PythonWin both use Scintilla, although in
slightly
> different fashions.

And as far as I know, Scintilla hasn't been ported to the Mac, and possibly
other python-enabled platforms.

<snip>

--Dethe



From pobrien@orbtech.com  Wed Jun 20 22:27:21 2001
From: pobrien@orbtech.com (Patrick K. O'Brien)
Date: Wed, 20 Jun 2001 16:27:21 -0500
Subject: [Tutor] Re: [Edu-sig] RE: [Idle-dev] IDLE's  save-before-run requirement
In-Reply-To: <5.1.0.14.1.20010620125502.00ab55c8@laplaza.org>
Message-ID: <NBBBIOJPGKJEKIECEMCBAEBGKBAA.pobrien@orbtech.com>

If we wrapped the necessary bits around Scintilla it might not be too hard.
At least we'd be starting with a lot of editor functionality - colorizing,
key bindings, code folding, etc. From what I understand Boa and PythonWin
both borrowed from IDLE but used Scintilla. I love Boa but it's design goal
is not the same as IDLE's. I also like PythonWin, but again, different
design goal. So what I would propose is a Scintilla-based (for lack of a
better alternative) IDE that is cross-platform (to the extent possible, but
at least Win and Linux and, hopefully, Mac), interactive, easy, helpful and
part of the standard distribution. I could help manage the process, but I'm
not up to the challenge of doing all the code.

---
Patrick K. O'Brien
Orbtech
"I am, therefore I think."

-----Original Message-----
From: edu-sig-admin@python.org [mailto:edu-sig-admin@python.org]On Behalf Of
Mats Wichmann
Sent: Wednesday, June 20, 2001 1:57 PM
To: pobrien@orbtech.com; idle-dev@python.org; Python Edu SIG; Python Tutor
Subject: RE: [Tutor] Re: [Edu-sig] RE: [Idle-dev] IDLE's save-before-run
requirement

 >And it would be
 >nice if these were GUI independent so that we could go from Tkinter to
 >wxWindows, for example, if we wanted to.

I once asked about something like this.  I believe right now
IDLE, at least, is not constructed in such a way that it
would be easy to rip out the Tkinter dependence so it could
be changed to something else, either permanently or for
plug-replacable graphics toolkits.

I wonder how much work that really would be, and if anybody
has any interest in it.  Not sure if there's really enough
value to be gained to make it worthwhile.

Mats


_______________________________________________
Edu-sig mailing list
Edu-sig@python.org
http://mail.python.org/mailman/listinfo/edu-sig



From pobrien@orbtech.com  Wed Jun 20 22:34:57 2001
From: pobrien@orbtech.com (Patrick K. O'Brien)
Date: Wed, 20 Jun 2001 16:34:57 -0500
Subject: [Tutor] Re: [Edu-sig] RE: [Idle-dev] IDLE "deemphasised"? Please not so...
In-Reply-To: <B7565384.CFE%delza@alliances.org>
Message-ID: <NBBBIOJPGKJEKIECEMCBAEBHKBAA.pobrien@orbtech.com>

Except that the VPython folks have a design goal that is quite tangential to
IDLE's. They need a tool to support their visual python modules (which allow
the manipulation of 3D objects and should not to be confused with
ActiveState's IDE) and the teaching of physics. While I do think their needs
should be accomodated, I don't know that they would want to be responsible
for IDLE development as a whole. (But I could be wrong.)

I've added them to the recipients of this message. We'll see if they
respond. (The vpython list has been quiet lately.)
---
Patrick K. O'Brien
Orbtech
"I am, therefore I think."

-----Original Message-----
From: tutor-admin@python.org [mailto:tutor-admin@python.org]On Behalf Of
Dethe Elza
Sent: Wednesday, June 20, 2001 3:20 PM
To: IDLE Developers List
Cc: Python Edu SIG; Python Tutor
Subject: [Tutor] Re: [Edu-sig] RE: [Idle-dev] IDLE "deemphasised"? Please
not so...

That's great news!  Are the VPython folks listening?

--Dethe

on 01/6/20 11:06 AM, Guido van Rossum at guido@digicool.com wrote:

>> It seems to me that the VPython folk are the perfect ones to pick up the
>> IDLE development reins.  They're actively working on IDLE already, have
>> already implemented the autosave mentioned, as well as some others, and
>> generally seem willing and interested.  I'm not sure what the reasoning
is
>> for keeping the VPython IDLE off in its own fork and not bringing it in
as
>> the official IDLE, since it is being actively developed.
>
> I think it was that I wanted to keep control over the direction in
> which IDLE was going.  The idle-fork SourceForge project was created
> so they could do their development.  But I don't think much happened
> there, and I haven't really done much except stifle IDLE development,
> so I'm ready to relax my control.  I do have that subprocess-running
> code which I would like to get worked into IDLE first though...
>
> --Guido van Rossum (home page: http://www.python.org/~guido/)
>
>

--

Dethe Elza
Chief Mad Scientist
Burning Tiger Technologies



_______________________________________________
Tutor maillist  -  Tutor@python.org
http://mail.python.org/mailman/listinfo/tutor



From guido@digicool.com  Wed Jun 20 22:44:17 2001
From: guido@digicool.com (Guido van Rossum)
Date: Wed, 20 Jun 2001 17:44:17 -0400
Subject: [Tutor] Re: [Edu-sig] RE: [Idle-dev] IDLE's save-before-run requirement
In-Reply-To: Your message of "Wed, 20 Jun 2001 16:27:21 CDT."
 <NBBBIOJPGKJEKIECEMCBAEBGKBAA.pobrien@orbtech.com>
References: <NBBBIOJPGKJEKIECEMCBAEBGKBAA.pobrien@orbtech.com>
Message-ID: <200106202144.f5KLiHa02304@odiug.digicool.com>

> So what I would propose is a Scintilla-based (for lack of a
> better alternative) IDE that is cross-platform (to the extent possible, but
> at least Win and Linux and, hopefully, Mac), interactive, easy, helpful and
> part of the standard distribution. I could help manage the process, but I'm
> not up to the challenge of doing all the code.

IDLE has most of the functionality (not code folding).

Why start over when there's probably a person-year of work in IDLE?

--Guido van Rossum (home page: http://www.python.org/~guido/)


From israel@lith.com  Wed Jun 20 22:49:07 2001
From: israel@lith.com (Israel Evans)
Date: Wed, 20 Jun 2001 14:49:07 -0700
Subject: [Tutor] Re: [Edu-sig] RE: [Idle-dev] IDLE's save-before-run r
 equirement
Message-ID: <AF020C5FC551DD43A4958A679EA16A15A144DE@mailcluster.lith.com>

What would switching over to using Scintilla accomplish that sticking with
IDLE and continuing it's development wouldn't?


-----Original Message-----
From: Guido van Rossum [mailto:guido@digicool.com]
Sent: Wednesday, June 20, 2001 2:44 PM
To: pobrien@orbtech.com
Cc: Mats Wichmann; idle-dev@python.org; Python Edu SIG; Python Tutor
Subject: Re: [Tutor] Re: [Edu-sig] RE: [Idle-dev] IDLE's save-before-run
requirement


> So what I would propose is a Scintilla-based (for lack of a
> better alternative) IDE that is cross-platform (to the extent possible,
but
> at least Win and Linux and, hopefully, Mac), interactive, easy, helpful
and
> part of the standard distribution. I could help manage the process, but
I'm
> not up to the challenge of doing all the code.

IDLE has most of the functionality (not code folding).

Why start over when there's probably a person-year of work in IDLE?

--Guido van Rossum (home page: http://www.python.org/~guido/)

_______________________________________________
Tutor maillist  -  Tutor@python.org
http://mail.python.org/mailman/listinfo/tutor


From pobrien@orbtech.com  Wed Jun 20 23:36:00 2001
From: pobrien@orbtech.com (Patrick K. O'Brien)
Date: Wed, 20 Jun 2001 17:36:00 -0500
Subject: [Tutor] Re: [Edu-sig] RE: [Idle-dev] IDLE's save-before-run requirement
In-Reply-To: <200106202144.f5KLiHa02304@odiug.digicool.com>
Message-ID: <NBBBIOJPGKJEKIECEMCBKEBKKBAA.pobrien@orbtech.com>

Maybe it's a really bad idea. My thinking went along these lines - Scintilla
seems to be getting a lot of support and other tools (Boa and PythonWin) are
using it. Those developers must have thought there was a compelling reason
to do so. If we went with Scintilla, that eliminates the whole text editing
burden and allows the tool to benefit from enhancements to Scintilla that
seem to be coming out at a nice pace. With that eliminated we could
concentrate on extracting the other good bits from IDLE and separating them
from the GUI so that one or more GUI toolkits could be used in addition to
Tkinter. Please understand that I'm just exploring an idea and meant no
disrespect. I can appreciate the effort that has gone into IDLE. Maybe my
suggestion is the wrong way to go about allowing IDLE development to
continue and to accommodate a variety of needs.

---
Patrick K. O'Brien
Orbtech
"I am, therefore I think."

-----Original Message-----
From: tutor-admin@python.org [mailto:tutor-admin@python.org]On Behalf Of
Guido van Rossum
Sent: Wednesday, June 20, 2001 4:44 PM
To: pobrien@orbtech.com
Cc: Mats Wichmann; idle-dev@python.org; Python Edu SIG; Python Tutor
Subject: Re: [Tutor] Re: [Edu-sig] RE: [Idle-dev] IDLE's save-before-run
requirement

> So what I would propose is a Scintilla-based (for lack of a
> better alternative) IDE that is cross-platform (to the extent possible,
but
> at least Win and Linux and, hopefully, Mac), interactive, easy, helpful
and
> part of the standard distribution. I could help manage the process, but
I'm
> not up to the challenge of doing all the code.

IDLE has most of the functionality (not code folding).

Why start over when there's probably a person-year of work in IDLE?

--Guido van Rossum (home page: http://www.python.org/~guido/)

_______________________________________________
Tutor maillist  -  Tutor@python.org
http://mail.python.org/mailman/listinfo/tutor



From pobrien@orbtech.com  Wed Jun 20 23:58:03 2001
From: pobrien@orbtech.com (Patrick K. O'Brien)
Date: Wed, 20 Jun 2001 17:58:03 -0500
Subject: [Tutor] Re: [Edu-sig] RE: [Idle-dev] IDLE's save-before-run requirement
In-Reply-To: <AF020C5FC551DD43A4958A679EA16A15A144DE@mailcluster.lith.com>
Message-ID: <NBBBIOJPGKJEKIECEMCBGEBMKBAA.pobrien@orbtech.com>

I'm not 100% sure. I just have the impression that IDLE is too closely tied
to Tkinter, that Guido doesn't have as much time to devote to IDLE, that
Scintilla might remove part of the burden, and that Scintilla has been used
successfully by other tools, namely Boa and PythonWin. I just see a lot of
duplication of effort with basic editing/interactive functionality that
strikes me as a waste of resources. Here are the tools that I use that all
have separate code bases though they all borrowed from IDLE. (I don't really
want to use this many, but I have to for various reasons.)

IDLE
Boa Constructor
VPython (Visual Python)
PythonWin

Each of these is annoyingly different in rudimentary ways. For example, each
of these has separate keybindings and separate ways of modifying
keybindings. They don't all support the same command line options. They
don't all honor startup scripts. Not all python programs will run
successfully in all of these IDEs. Not all of these IDEs will run on all of
the platforms that Python itself will run on. Etc., etc.

There are just too darn many unnecessary variations, imho. I have spent way
too much time trying to get a productive environment in each of these tools
and getting them to all honor keystrokes and startup scripts that I find
useful.

To me it would be ideal if there were one or more core modules that
supported the editing of python files and interactive sessions. Each tool
would build on these modules for their own design goals, but the basics
would be there for everyone. The fact that all these tools have forked from
IDLE or borrowed heavily from IDLE suggests that there was something missing
or inadequate in the opinions of these other IDE developers. I'm trying to
understand what that missing element was and see if we can establish some
basic functionality, some architecture, rather than perpetuate this
diversity. I like Python because it has one right way for everything ...
except writing and running the actual code.

All I am asking is how do we apply the "one right way" attitude to the IDE
situation?

---
Patrick K. O'Brien
Orbtech
"I am, therefore I think."

-----Original Message-----
From: tutor-admin@python.org [mailto:tutor-admin@python.org]On Behalf Of
Israel Evans
Sent: Wednesday, June 20, 2001 4:49 PM
To: 'Guido van Rossum'; pobrien@orbtech.com
Cc: Mats Wichmann; idle-dev@python.org; Python Edu SIG; Python Tutor
Subject: RE: [Tutor] Re: [Edu-sig] RE: [Idle-dev] IDLE's save-before-run
requirement

What would switching over to using Scintilla accomplish that sticking with
IDLE and continuing it's development wouldn't?



From delza@alliances.org  Thu Jun 21 00:13:59 2001
From: delza@alliances.org (Dethe Elza)
Date: Wed, 20 Jun 2001 16:13:59 -0700
Subject: [Tutor] Re: [Edu-sig] RE: [Idle-dev] IDLE's save-before-run
 requirement
In-Reply-To: <NBBBIOJPGKJEKIECEMCBGEBMKBAA.pobrien@orbtech.com>
Message-ID: <B7567C47.D25%delza@alliances.org>

on 01/6/20 03:58 PM, Patrick K. O'Brien at pobrien@orbtech.com wrote:

> All I am asking is how do we apply the "one right way" attitude to the IDE
> situation?

I don't have an answer, but it's a damn good question.

-- 

Dethe Elza 
Chief Mad Scientist
Burning Tiger Technologies




From bas@andrew.cmu.edu  Thu Jun 21 00:29:59 2001
From: bas@andrew.cmu.edu (Bruce Sherwood)
Date: Wed, 20 Jun 2001 19:29:59 -0400
Subject: [Idle-dev] Re: [Visualpython-users] RE: [Tutor] Re: [Edu-sig] RE: [Idle-dev]
 IDLE "deemphasised"? Please not so...
In-Reply-To: <NBBBIOJPGKJEKIECEMCBAEBHKBAA.pobrien@orbtech.com>
Message-ID: <927954124.993065399@HYPERON.REM.CMU.EDU>

Concerning VPython and IDLE:

At the same time that he created the Visual module, which provides 
remarkably easy 3D animated graphics for Python (Visual + Python = 
VPython), David Scherer made major changes to IDLE, including:

   executes scripts in a separate process for stability
   excludes system modules from tracebacks
   usability changes, including reorganized menus
   autosave on every run, with infinite un-do
   scrolling output has a header marking the start of each run

This has turned out to be an ideal environment for novices (as measured by 
use by a large number of physics students), and is also an excellent rapid 
edit-run environment for experts.

Alas, there is no active work on this at present, because Scherer is not 
currently in a situation where he can spend time on this, and we have no 
one else in the project currently capable of pushing this forward.

It is certainly the case that Scherer's version of IDLE is an exceptionally 
promising candidate to become the "official" IDLE, but unfortunately we are 
not able to lead the charge right now.

Bruce Sherwood

P.S. We have just released VPython for Python 2.1 on Windows:

   http://cil.andrew.cmu.edu/projects/visual

This new release installs Scherer's IDLE in Tools/idle_VPython, leaving the 
standard IDLE in place. Desktop and start-menu icons are added that access 
the VPython version of IDLE.



From kevino@tulane.edu  Thu Jun 21 01:48:36 2001
From: kevino@tulane.edu (Kevin Ollivier)
Date: Wed, 20 Jun 2001 20:48:36 -0400
Subject: [Tutor] Re: [Edu-sig] RE: [Idle-dev] IDLE's save-before-runrequirement
References: <B7567C47.D25%delza@alliances.org>
Message-ID: <006e01c0f9eb$e7b985e0$6401a8c0@cox.rr.com>

Hi everyone,

I agree that it is a (ahem!) darn good question. =) And the issue Patrick
brought up about the many IDE projects "re-inventing the wheel" is a great
one as well. One trend I see with open source development is that there are
generally many projects being built to solve the same problem, but doing so
in slightly different ways. So there is no doubt that there is a lot of
'duplicate' code being written out there, and I feel the various IDE
developers out there should really work out some common standards. Of course
the issue with open source projects at least is that most of them are built
"to scratch an itch", so to speak, so the programmer is focused on meeting
his/her needs and issues like compatibility are not often addressed.

With regards to IDLE, if I may make a suggestion, I think before we decide
on how IDLE is to get where it is going, we should first decide on where it
is going. What features should IDLE have? What is the "vision" for IDLE?
Will it become a power-IDE with features galore attempting to replace the
IDEs out there, or stay clean and simple, like Python itself? Should it be
Win/Mac/Linux compatible in one package, or is it OK that the Mac
implementation is different? And to pose a question that was brought up on
the Edu-sig list last weekend: Should there be "teaching" features built
into IDLE to help beginners learn the language? (i.e. IDLE, in "training
mode", would pose programming problems and point out mistakes) More
importantly, who's going do do all this work?? =)

As a stray thought, how easy would it be to have some of these features
added "dynamically"? In other words, make features like the color coding and
code-folding, or even interactive training, into modules that could be
imported by the user. That sort of thing. I think Patrick touched upon this
in his earlier message. How much work would this be? Or has this sort of
thing already been done?

My two cents? I think it would be really cool to advance IDLE to have a
built-in "training mode" so that everything you need to get up and running
with Python comes "in the box". In a way, the CP4E and IDLE projects could
become one and the same! (OK, so maybe this is just a dream, but it's a nice
one!) Making a Win/Mac/Linux version seems like a good idea, but I think it
depends on how much work it is, or realistically how much work will be put
into future versions. The features of the editor itself don't seem to bad
too me personally. After playing with a lot of "full-featured" IDEs, I
settled with a text editor. (Embarrassingly enough, I did not realize that
IDLE was also a script editor - I thought it was only a interpreter!) I
found the other IDEs to be big and bulky, and the bigger they were, the more
bugs and stability problems they had. Of course, I'm on Windows too, so
there are other factors there... =)

What do others think? I hope I've not gotten on a soapbox and babbled here.
I do have a tendency to do that on occasion... <AHEM!> I'm actually new to
all this open-source, mailing list stuff so if I'm breaking etiquette rules
or something feel free to tell me! ^_^;

Thanks for listening!

Kevin Ollivier

----- Original Message -----
From: "Dethe Elza" <delza@alliances.org>
To: <idle-dev@python.org>; "Python Edu SIG" <Edu-sig@python.org>; "Python
Tutor" <tutor@python.org>
Sent: Wednesday, June 20, 2001 7:13 PM
Subject: Re: [Tutor] Re: [Edu-sig] RE: [Idle-dev] IDLE's
save-before-runrequirement


> on 01/6/20 03:58 PM, Patrick K. O'Brien at pobrien@orbtech.com wrote:
>
> > All I am asking is how do we apply the "one right way" attitude to the
IDE
> > situation?
>
> I don't have an answer, but it's a damn good question.
>
> --
>
> Dethe Elza
> Chief Mad Scientist
> Burning Tiger Technologies
>
>
>
> _______________________________________________
> Edu-sig mailing list
> Edu-sig@python.org
> http://mail.python.org/mailman/listinfo/edu-sig
>



From pobrien@orbtech.com  Thu Jun 21 02:49:46 2001
From: pobrien@orbtech.com (Patrick K. O'Brien)
Date: Wed, 20 Jun 2001 20:49:46 -0500
Subject: [Tutor] Re: [Edu-sig] RE: [Idle-dev] IDLE's save-before-runrequirement
In-Reply-To: <006e01c0f9eb$e7b985e0$6401a8c0@cox.rr.com>
Message-ID: <NBBBIOJPGKJEKIECEMCBKECBKBAA.pobrien@orbtech.com>

Well said. I agree with all your suggestions and opinions, especially on
getting agreement on where we are going. I probably jumped the gun a bit by
suggesting a direction that might not be where everyone else wants to go.
Your take on the situation is much appreciated.

---
Patrick K. O'Brien
Orbtech
"I am, therefore I think."

-----Original Message-----
From: idle-dev-admin@python.org [mailto:idle-dev-admin@python.org]On Behalf
Of Kevin Ollivier
Sent: Wednesday, June 20, 2001 7:49 PM
To: idle-dev@python.org; Python Edu SIG; Python Tutor
Subject: Re: [Tutor] Re: [Edu-sig] RE: [Idle-dev] IDLE's
save-before-runrequirement

Hi everyone,

I agree that it is a (ahem!) darn good question. =) And the issue Patrick
brought up about the many IDE projects "re-inventing the wheel" is a great
one as well. One trend I see with open source development is that there are
generally many projects being built to solve the same problem, but doing so
in slightly different ways. So there is no doubt that there is a lot of
'duplicate' code being written out there, and I feel the various IDE
developers out there should really work out some common standards. Of course
the issue with open source projects at least is that most of them are built
"to scratch an itch", so to speak, so the programmer is focused on meeting
his/her needs and issues like compatibility are not often addressed.

With regards to IDLE, if I may make a suggestion, I think before we decide
on how IDLE is to get where it is going, we should first decide on where it
is going. What features should IDLE have? What is the "vision" for IDLE?
Will it become a power-IDE with features galore attempting to replace the
IDEs out there, or stay clean and simple, like Python itself? Should it be
Win/Mac/Linux compatible in one package, or is it OK that the Mac
implementation is different? And to pose a question that was brought up on
the Edu-sig list last weekend: Should there be "teaching" features built
into IDLE to help beginners learn the language? (i.e. IDLE, in "training
mode", would pose programming problems and point out mistakes) More
importantly, who's going do do all this work?? =)

As a stray thought, how easy would it be to have some of these features
added "dynamically"? In other words, make features like the color coding and
code-folding, or even interactive training, into modules that could be
imported by the user. That sort of thing. I think Patrick touched upon this
in his earlier message. How much work would this be? Or has this sort of
thing already been done?

My two cents? I think it would be really cool to advance IDLE to have a
built-in "training mode" so that everything you need to get up and running
with Python comes "in the box". In a way, the CP4E and IDLE projects could
become one and the same! (OK, so maybe this is just a dream, but it's a nice
one!) Making a Win/Mac/Linux version seems like a good idea, but I think it
depends on how much work it is, or realistically how much work will be put
into future versions. The features of the editor itself don't seem to bad
too me personally. After playing with a lot of "full-featured" IDEs, I
settled with a text editor. (Embarrassingly enough, I did not realize that
IDLE was also a script editor - I thought it was only a interpreter!) I
found the other IDEs to be big and bulky, and the bigger they were, the more
bugs and stability problems they had. Of course, I'm on Windows too, so
there are other factors there... =)

What do others think? I hope I've not gotten on a soapbox and babbled here.
I do have a tendency to do that on occasion... <AHEM!> I'm actually new to
all this open-source, mailing list stuff so if I'm breaking etiquette rules
or something feel free to tell me! ^_^;

Thanks for listening!

Kevin Ollivier




From pdx4d@teleport.com  Thu Jun 21 04:03:10 2001
From: pdx4d@teleport.com (Kirby Urner)
Date: Wed, 20 Jun 2001 20:03:10 -0700
Subject: [Edu-sig] RE: [Idle-dev] IDLE's save-before-run requirement
In-Reply-To: <200106201807.f5KI7dL01340@odiug.digicool.com>
References: <Your message of "Wed, 20 Jun 2001 09:23:44 PDT." <4.2.0.58.20010620092102.00a39f00@pop3.norton.antivirus>
 <Pine.LNX.4.31.0106181704000.12659-100000@emperor.deirdre.org>
 <4.2.0.58.20010620092102.00a39f00@pop3.norton.antivirus>
Message-ID: <4.2.0.58.20010620200128.00948180@pop3.norton.antivirus>

At 02:07 PM 6/20/2001 -0400, Guido van Rossum wrote:

>But MacPython comes with its own IDE, built by Just van Rossum (my
>brother) using the native Mac toolbox.


So I presume MacPython has a shell for interactively importing
modules and using their contents.

Does it auto-color key words in the shell and in the editor
I wonder? ala IDLE in Win/Linux?

The reason I ask is (a) an interactive shell is very
important for learners and (b) iMacs are very popular in
many schools.

Kirby



From pdx4d@teleport.com  Thu Jun 21 04:26:16 2001
From: pdx4d@teleport.com (Kirby Urner)
Date: Wed, 20 Jun 2001 20:26:16 -0700
Subject: [Tutor] Re: [Edu-sig] RE: [Idle-dev] IDLE's
 save-before-runrequirement
In-Reply-To: <006e01c0f9eb$e7b985e0$6401a8c0@cox.rr.com>
References: <B7567C47.D25%delza@alliances.org>
Message-ID: <4.2.0.58.20010620201438.00d1c800@pop3.norton.antivirus>

>
>What do others think? I hope I've not gotten on a soapbox and babbled here.
>I do have a tendency to do that on occasion... <AHEM!> I'm actually new to
>all this open-source, mailing list stuff so if I'm breaking etiquette rules
>or something feel free to tell me! ^_^;
>
>Thanks for listening!
>
>Kevin Ollivier

I've always thought IDLE was 98% of what's needed.  I like these
widgets in other IDEs that prompt you with all the possible
class methods when you go >>> foo. -- but that's a bell I can
live without.

When it comes to teaching in the classroom, I think IDLE is a
fantastic tool -- as is.  Except it doesn't work on the Mac.
But maybe MacPython fills that void (wish wish).

The major shortcoming of IDLE seems to be that it doesn't do
the Tk stuff in a separate thread, so you quit IDLE when you
quit the Tkinter program you're working on.  So maybe that's
what Guido is talking about re running IDLE as a subprocess --
adding that before opening IDLE development to a larger group.

As another poster pointed out, a lot of the GUI-development
seems to be moving towards XML-based descriptions -- much as
HTML is used to spec out interactive forms, only x100 in power.
Perhaps GUI development is too much in flux across the board
to try hammering down some cross-platform "one right way" at
this point.  There will be more shake-outs down the road.

The main thing I like about IDLE is you can import modules in
shell mode and interact with them in a conversational manner.
You can have a lot of persistent handles to your objects, which
you can play with -- literally.

Basically, the user's mind becomes main(), the outer loop, and
you've got persistence for the duration of the session.

This is way different from just using an editor, where you have
to have all your ducks in a row up front, before you commit
the script to the interpreter.

I like the free form scratch pad feel of IDLE work, which makes
it feel a lot like an OS.

I think of the GUIs as various idioms in the toolbox -- like
that Glade stuff for Gnome (with which I have no personal experience
as yet).

Kirby



From pdx4d@teleport.com  Thu Jun 21 04:27:44 2001
From: pdx4d@teleport.com (Kirby Urner)
Date: Wed, 20 Jun 2001 20:27:44 -0700
Subject: [Visualpython-users] RE: [Tutor] Re: [Edu-sig] RE:
 [Idle-dev] IDLE "deemphasised"? Please not so...
In-Reply-To: <927954124.993065399@HYPERON.REM.CMU.EDU>
References: <NBBBIOJPGKJEKIECEMCBAEBHKBAA.pobrien@orbtech.com>
Message-ID: <4.2.0.58.20010620202719.00a6df00@pop3.norton.antivirus>

>
>P.S. We have just released VPython for Python 2.1 on Windows:
>
>   http://cil.andrew.cmu.edu/projects/visual
>
>This new release installs Scherer's IDLE in Tools/idle_VPython, leaving 
>the standard IDLE in place. Desktop and start-menu icons are added that 
>access the VPython version of IDLE.


Excellent!!

I'm gonna grab mine now.

Cheers,

Kirby



From pdx4d@teleport.com  Thu Jun 21 04:36:32 2001
From: pdx4d@teleport.com (Kirby Urner)
Date: Wed, 20 Jun 2001 20:36:32 -0700
Subject: [Visualpython-users] RE: [Tutor] Re: [Edu-sig] RE:
 [Idle-dev] IDLE "deemphasised"? Please not so...
In-Reply-To: <4.2.0.58.20010620202719.00a6df00@pop3.norton.antivirus>
References: <927954124.993065399@HYPERON.REM.CMU.EDU>
 <NBBBIOJPGKJEKIECEMCBAEBHKBAA.pobrien@orbtech.com>
Message-ID: <4.2.0.58.20010620203505.00cffce0@pop3.norton.antivirus>

At 08:27 PM 6/20/2001 -0700, Kirby Urner wrote:


>>P.S. We have just released VPython for Python 2.1 on Windows:
>>
>>   http://cil.andrew.cmu.edu/projects/visual
>>
>>This new release installs Scherer's IDLE in Tools/idle_VPython, leaving 
>>the standard IDLE in place. Desktop and start-menu icons are added that 
>>access the VPython version of IDLE.
>
>
>Excellent!!
>
>I'm gonna grab mine now.
>
>Cheers,
>
>Kirby

Took only seconds to grab and install.  Works like a charm.

Arthur, your PyGeo package is running way smoother now that I
have an official VPython 2.1.   Pascal3d is trouble free -- was
something of a mess earlier.  This is great!

Kirby



From alan.gauld@bt.com  Thu Jun 21 12:43:31 2001
From: alan.gauld@bt.com (alan.gauld@bt.com)
Date: Thu, 21 Jun 2001 12:43:31 +0100
Subject: [Tutor] Re: [Edu-sig] RE: [Idle-dev] IDLE's save-before-run r
 equirement
Message-ID: <5104D4DBC598D211B5FE0000F8FE7EB20751D846@mbtlipnt02.btlabs.bt.co.uk>

> What would switching over to using Scintilla accomplish that 
> sticking with IDLE and continuing it's development wouldn't?

In a word "Reuse". That means one editor to maintain for most 
of the Python IDEs. Add a feature to Scintilla and its pretty 
trivial for all the IDEs to pick up the new feature without 
having to reimplemnent it from scratch. Effort gets concentrated 
on the value add bits rather than the nitty gritty of text editing.

At least that's the theory... In practice writing reusable 
solutions gets exponentially harder with the number of clients.
Thus trying to please multiple consumers might just wind up
stifleing the development of Scintilla!

Personally my favourite approach to IDEs is that taken by 
the old HP Unix product - provide a configurable framework and 
let the user select their own editor/compiler/interpreter/debugger
etc. The downside of this is that it restricts how much integration 
you can really have to how well integrated the selected tools are.
GNOME etc should make this approach more viable long term. 

Alan G


From guido@digicool.com  Thu Jun 21 13:40:35 2001
From: guido@digicool.com (Guido van Rossum)
Date: Thu, 21 Jun 2001 08:40:35 -0400
Subject: [Tutor] Re: [Edu-sig] RE: [Idle-dev] IDLE's save-before-run r equirement
In-Reply-To: Your message of "Thu, 21 Jun 2001 12:43:31 BST."
 <5104D4DBC598D211B5FE0000F8FE7EB20751D846@mbtlipnt02.btlabs.bt.co.uk>
References: <5104D4DBC598D211B5FE0000F8FE7EB20751D846@mbtlipnt02.btlabs.bt.co.uk>
Message-ID: <200106211240.IAA30865@cj20424-a.reston1.va.home.com>

> > What would switching over to using Scintilla accomplish that 
> > sticking with IDLE and continuing it's development wouldn't?
> 
> In a word "Reuse". That means one editor to maintain for most 
> of the Python IDEs. Add a feature to Scintilla and its pretty 
> trivial for all the IDEs to pick up the new feature without 
> having to reimplemnent it from scratch. Effort gets concentrated 
> on the value add bits rather than the nitty gritty of text editing.

But IDLE has a bunch of requirements that I don't think Scintilla can
provide.  IDLE has really two editing modes: the regular module/file
editor, and the "Python Shell".  IDLE's most redeeming feature, IMO,
is the Python Shell.  Compare editing an interactive session in
PythonWin's console window with IDLE's Python Shell.  IMO again, IDLE
is infinitely better, because it uses the exact same editing features
as the module/file editor, meaning you get proper syntax coloring,
automatic indentation, call tips, magic expansion; and on top of that
you get per-line syntax checking, whole-command editing, and history
recall.  In PythonWin's much more primitive console, it's very easy to
mess up the input or the output or confuse the auto-indenter.

(I'm an instant gratification person, so Python's interactive mode is
very important to me.)

I could be wrong about Scintilla not supporting this, but if it did,
why would PythonWin not use it for *its* console?

--Guido van Rossum (home page: http://www.python.org/~guido/)


From elguavas@users.sourceforge.net  Thu Jun 21 15:39:44 2001
From: elguavas@users.sourceforge.net (stephen)
Date: Fri, 22 Jun 2001 00:39:44 +1000
Subject: [Tutor] Re: [Edu-sig] RE: [Idle-dev] IDLE's save-before-run r equirement
In-Reply-To: <200106211240.IAA30865@cj20424-a.reston1.va.home.com>
References: <5104D4DBC598D211B5FE0000F8FE7EB20751D846@mbtlipnt02.btlabs.bt.co.uk> <200106211240.IAA30865@cj20424-a.reston1.va.home.com>
Message-ID: <01062200354900.01178@oberon.casa-guava.org>

> > > What would switching over to using Scintilla accomplish that
> > > sticking with IDLE and continuing it's development wouldn't?
> >
> > In a word "Reuse". That means one editor to maintain for most
> > of the Python IDEs. Add a feature to Scintilla and its pretty
> > trivial for all the IDEs to pick up the new feature without
> > having to reimplemnent it from scratch. Effort gets concentrated
> > on the value add bits rather than the nitty gritty of text editing.
>
> But IDLE has a bunch of requirements that I don't think Scintilla can
> provide.  IDLE has really two editing modes: the regular module/file
> editor, and the "Python Shell".  IDLE's most redeeming feature, IMO,
> is the Python Shell.  Compare editing an interactive session in
> PythonWin's console window with IDLE's Python Shell.  IMO again, IDLE
> is infinitely better, because it uses the exact same editing features
> as the module/file editor, meaning you get proper syntax coloring,
> automatic indentation, call tips, magic expansion; and on top of that
> you get per-line syntax checking, whole-command editing, and history
> recall.  In PythonWin's much more primitive console, it's very easy to
> mess up the input or the output or confuse the auto-indenter.
>
> (I'm an instant gratification person, so Python's interactive mode is
> very important to me.)
>
> I could be wrong about Scintilla not supporting this, but if it did,
> why would PythonWin not use it for *its* console?

Scintilla is just a sophisticated editor component (and it seems to be a 
jolly nice one too). All this talk about using scintilla in IDLE is rather a 
moot point because the fact is it is built on a different gui toolkit to IDLE 
and to have just one part of IDLE (the code editor) based on a different 
toolkit to the rest of IDLE would be just silly. Tearing out just some code 
from IDLE and remaking all of it again with a different gui toolkit just for 
compatibility with a different editing component would also be just silly.

The fact is that the beauty of IDLE, and of its being built in tkinter, is 
that it's small, light and relatively simple and the gui toolkit is available 
by default and working on most platforms python works on. If you 
look back to the earlier parts of the threads that led to here you will find 
this is exactly what many folk, including those in EDU_SIG, are looking for 
from IDLE, and it is the right level and place for the IDE that is bundled in 
the python distribution to be pitched at, particularly the independance from 
third party gui libraries.

In the case of the rather different need for an  IDE that is all singing and 
dancing, there are other projects out there who have this aim (and more are 
starting, if you search for 'python' on sourceforge there seem to be dozens 
of such project in the design or early phases) so there is plenty of scope 
for those who'd like to see something like 'delphi for python' arrive (a 
worthy aim!) to find a project to participate in that is working toward these 
ends. It's a different kind of project for a different end.

I'd like to see the changes from the Vpython guys folded in where appropriate 
(Guido: if they've already implemented running the apps in a different 
process, have they already solved your security problem...?  Vpython guys??) 
and IDLE to definitely keep on moving forward in the track it is already 
following, with no bathwater or babies thrown out. The IDLE editor is quite 
appropriate and suitable for its job in IDLE.

Regards IDLErs,
Stephen.
-- 
<elguavas@users.sourceforge.net>
More power to those who don't care for it.



From pobrien@orbtech.com  Thu Jun 21 16:16:33 2001
From: pobrien@orbtech.com (Patrick K. O'Brien)
Date: Thu, 21 Jun 2001 10:16:33 -0500
Subject: [Idle-dev] Python Shell - was: RE: IDLE's save-before-run r equirement
In-Reply-To: <200106211240.IAA30865@cj20424-a.reston1.va.home.com>
Message-ID: <NBBBIOJPGKJEKIECEMCBCEDBKBAA.pobrien@orbtech.com>

Thank you, Guido, for bearing with me on this whole issue. I think we are
getting to the heart of the matter. Because I, too, am an instant
gratification person. So let's just talk about the Python Shell
(interactive) capabilities as they exist in the various IDEs. I will attempt
to explain my take on this situation, what bothers me, and what I'd like to
see happen.

The four tools under discussion. IDLE, Boa, PythonWin and VPython all have a
Python Shell capability. But they all vary in their support of keybindings,
coloring, indenting, etc. When someone uses all of these tools and makes use
of each Shell, they have to keep in mind all the variations that exist. This
is counter-productive and takes away from what should be "instant
gratification at all times." I would rather have a common feature set within
all Shells, even if it meant giving up features, rather than have the
variations that exist now. I would like to see the Python Shell exist as
some kind of plug-in or shared code base that all the IDEs could use so that
the Python Shell was uniform in all tools on all platforms. I think this
fits the Python philosophy and would make life a lot easier for beginners as
well as experts. It would also make the Shell available for new,
special-case tools that have been discussed, such as a Python Tutor or
Python Trivial Pursuit game, where the variations would be solely within the
value-add portions and not the fundamental Shell capability (and without
creating yet more forks).

Here are some specific examples of the variations that bother me (Please
don't anyone take offense at these comparisons. I believe they are all
objective, demonstrable differences and not just my opinion, though I am
clearly opinionated. And if I'm wrong about any of this please let me
know.):

PYTHONSTARTUP: IDLE and VPython support it with the -s command line switch.
Boa will have this feature in the next release (because I asked for it).
PythonWin has no support whatsoever for PYTHONSTARTUP to my knowledge.

Home key: Type a line of code at the shell prompt (>>>) and then hit the
Home key. PythonWin puts the cursor in front of your code (very nice). IDLE
and VPython put the cursor in front of the prompt and then beep when you try
to continue typing (yuck). Boa puts the cursor in front of the prompt and
lets you type over the prompt. When you hit enter it truncates the first
four characters from what you typed and tries to execute that (big yuck). I
use this feature a lot in PythonWin when I'm copying previous lines down and
want to get to the beginning of the line to add more code, like assigning to
a variable or some such. When I switch to one of the other tools I have to
do Home, Right, Right, Right, Right - way too many keystrokes.

Command history: IDLE and VPython have Alt-P (previous) and Alt-N (next),
which is very nice. PythonWin has a way to add these bindings, but by
default has Ctrl-Up and Ctrl-Down (just to be different?). I don't know how
to add the PythonWin bindings to IDLE or VPython. Boa has no command
history.

Call tips: PythonWin has the best as far as showing what is in a module.
IDLE/VPython have the best as far as showing function parameters and
docstrings. Boa is way behind.

Win32All: PythonWin is the only tool that can deal with the win extensions,
like dde or com. This is a major pain. There are times when I'd love to use
IDLE but since I'm developing a Windows app that requires DDE I can only use
PythonWin. (And I don't really understand why this is but it definitely
irritates me to no end.)

I'm sure there are other differences, but these are good enough to get my
point across. So I will finish with a question - What, if anything, can be
done about this situation, or am I barking up the wrong tree?

---
Patrick K. O'Brien
Orbtech
"I am, therefore I think."

-----Original Message-----
From: guido@cj20424-a.reston1.va.home.com
[mailto:guido@cj20424-a.reston1.va.home.com]On Behalf Of Guido van Rossum
Sent: Thursday, June 21, 2001 7:41 AM
To: alan.gauld@bt.com
Cc: israel@lith.com; pobrien@orbtech.com; mats@laplaza.org;
idle-dev@python.org; Edu-sig@python.org; tutor@python.org
Subject: Re: [Tutor] Re: [Edu-sig] RE: [Idle-dev] IDLE's save-before-run r
equirement

> > What would switching over to using Scintilla accomplish that
> > sticking with IDLE and continuing it's development wouldn't?
>
> In a word "Reuse". That means one editor to maintain for most
> of the Python IDEs. Add a feature to Scintilla and its pretty
> trivial for all the IDEs to pick up the new feature without
> having to reimplemnent it from scratch. Effort gets concentrated
> on the value add bits rather than the nitty gritty of text editing.

But IDLE has a bunch of requirements that I don't think Scintilla can
provide.  IDLE has really two editing modes: the regular module/file
editor, and the "Python Shell".  IDLE's most redeeming feature, IMO,
is the Python Shell.  Compare editing an interactive session in
PythonWin's console window with IDLE's Python Shell.  IMO again, IDLE
is infinitely better, because it uses the exact same editing features
as the module/file editor, meaning you get proper syntax coloring,
automatic indentation, call tips, magic expansion; and on top of that
you get per-line syntax checking, whole-command editing, and history
recall.  In PythonWin's much more primitive console, it's very easy to
mess up the input or the output or confuse the auto-indenter.

(I'm an instant gratification person, so Python's interactive mode is
very important to me.)

I could be wrong about Scintilla not supporting this, but if it did,
why would PythonWin not use it for *its* console?

--Guido van Rossum (home page: http://www.python.org/~guido/)



From pdx4d@teleport.com  Thu Jun 21 16:44:42 2001
From: pdx4d@teleport.com (Kirby Urner)
Date: Thu, 21 Jun 2001 08:44:42 -0700
Subject: [Idle-dev] Re: [Edu-sig] Python Shell - was: RE: IDLE's save-before-run r
 equirement
In-Reply-To: <NBBBIOJPGKJEKIECEMCBCEDBKBAA.pobrien@orbtech.com>
References: <200106211240.IAA30865@cj20424-a.reston1.va.home.com>
Message-ID: <4.2.0.58.20010621084319.00bc1a50@pop3.norton.antivirus>

>
>The four tools under discussion. IDLE, Boa, PythonWin and VPython

Should VPython really be included here?  When I ask for shell
mode in VPython, I get IDLE 0.5.  VPython is a variant on IDLE
is all, not a whole other IDE.

Kirby



From kbk@shore.net  Thu Jun 21 16:57:54 2001
From: kbk@shore.net (Kurt B. Kaiser)
Date: 21 Jun 2001 11:57:54 -0400
Subject: [Tutor] [Edu-sig] [Idle-dev] IDLE's save-before-run requirement
In-Reply-To: <200106211240.IAA30865@cj20424-a.reston1.va.home.com>
References: <5104D4DBC598D211B5FE0000F8FE7EB20751D846@mbtlipnt02.btlabs.bt.co.uk> <200106211240.IAA30865@cj20424-a.reston1.va.home.com>
Message-ID: <m3pubx25bx.fsf_-_@float.ne.mediaone.com>

Guido van Rossum <guido@digicool.com> writes:
 
> But IDLE has a bunch of requirements that I don't think Scintilla can
> provide.  IDLE has really two editing modes: the regular module/file
> editor, and the "Python Shell".  IDLE's most redeeming feature, IMO,
> is the Python Shell.  Compare editing an interactive session in
> PythonWin's console window with IDLE's Python Shell.  IMO again, IDLE
> is infinitely better, because it uses the exact same editing features
> as the module/file editor, meaning you get proper syntax coloring,
> automatic indentation, call tips, magic expansion; and on top of that
> you get per-line syntax checking, whole-command editing, and history
> recall.  In PythonWin's much more primitive console, it's very easy to
> mess up the input or the output or confuse the auto-indenter.
> 
> (I'm an instant gratification person, so Python's interactive mode is
> very important to me.)

An update of a post to idle-dev, made a couple of days ago:
IDLE is a very useful IDE for Python which has a unique set of features
compared to other solutions:

1. Open souce
2. Under ultimate control of GvR.
3. Portable via Tkinter.
4. Very usable by relatively inexperienced people.
5. Has a Python debugger.
6. Understands Python syntax and environment.
7. Provides an extended example of Python programming.
8. Distributed with most versions (no Mac because of current Tk limitations) 
   of Python at very reasonable cost, so available to first time, casual,
   or resource limited users.
9. Interactive shell has same features as module editor, e.g. colorizing

IMHO IDLE should remain at roughly the (apparent) level of complexity it's at
(or less?) to avoid reducing its usability for beginning/intermediate
programmers.  There are some things which can be done to further improve
usability and reliability, IMHO, like running the target code in a separate
process.

When people involved with Scheme, Forth, or Eiffel are looking for projects,
they tend to re-implement the language. Thank heavens that's not a major factor
with Python, thanks to GvR's leadership. But Pythonistas are clearly attracted
to implementing IDEs!

I can't see any reason why IDLE development should get tied in knots trying for
compatibility with other IDEs. That kind of thing can paralyze you! 

The plan last August, met with enthusiam at the time, was to continue to
develop IDLE on a separate fork to avoid the bottlenecks of new feature patch
review on the Python CVS. The hope was to merge back into the main branch in
the future. If that is to happen, we need to stay close to Guido's vision for
IDLE. When it comes to IDEs, there is more than one way to do it, but Guido has
shown us his way, and I'd vote for continuing along those lines.

With open source software, it appears to be extremely difficult to specify a
project via group interaction.  As just one example, take a look at LispOS
(archived at lists.tunes.org/archives/lispos).  A couple of dozen people argued
specs for nearly two years without any progress.  (Then a student at Utah
implemented in less than 10 hours a first cut at essentially what the LispOS
project was attempting and the project shut down.)  It appears that an initial
implementation is necessary, which can then be enhanced. Python does it by
formal PEP, GvR is suggesting a more informal approach for IDLE: simple
discussion on the idle-dev list.  IMHO, that will work for incremental change.
But as with PEPs, if the group response is favorable, the proposer is still
responsible for coding up a patch for evaluation.

Regards, KBK


From pobrien@orbtech.com  Thu Jun 21 16:57:33 2001
From: pobrien@orbtech.com (Patrick K. O'Brien)
Date: Thu, 21 Jun 2001 10:57:33 -0500
Subject: [Idle-dev] RE: [Edu-sig] Python Shell - was: RE: IDLE's save-before-run r  equirement
In-Reply-To: <4.2.0.58.20010621084319.00bc1a50@pop3.norton.antivirus>
Message-ID: <NBBBIOJPGKJEKIECEMCBCEDEKBAA.pobrien@orbtech.com>

Well, the current IDLE is 0.8. So any difference in the Shell capability
between 0.5 and 0.8 are going to show up. And if VPython remains at 0.5 this
will become more of an issue over time. And if the Edu sig decides to do a
IDLE Tutorial fork then we are just making things worse, imo. I just can't
help feeling that these IDLE variants are not a very good thing because they
are complete forks and not just add-ons or plug-ins. On the other hand, you
are correct that the differences right now between the IDLE and VPython
shells is minor or possibly even nonexistent.

---
Patrick K. O'Brien
Orbtech
"I am, therefore I think."

-----Original Message-----
From: Kirby Urner [mailto:pdx4d@teleport.com]
Sent: Thursday, June 21, 2001 10:45 AM
To: pobrien@orbtech.com
Cc: idle-dev@python.org; Edu-sig@python.org
Subject: Re: [Edu-sig] Python Shell - was: RE: IDLE's save-before-run r
equirement


>
>The four tools under discussion. IDLE, Boa, PythonWin and VPython

Should VPython really be included here?  When I ask for shell
mode in VPython, I get IDLE 0.5.  VPython is a variant on IDLE
is all, not a whole other IDE.

Kirby



From pdx4d@teleport.com  Thu Jun 21 17:40:20 2001
From: pdx4d@teleport.com (Kirby Urner)
Date: Thu, 21 Jun 2001 09:40:20 -0700
Subject: [Idle-dev] RE: [Edu-sig] Python Shell - was: RE: IDLE's save-before-run r
 equirement
In-Reply-To: <NBBBIOJPGKJEKIECEMCBCEDEKBAA.pobrien@orbtech.com>
References: <4.2.0.58.20010621084319.00bc1a50@pop3.norton.antivirus>
Message-ID: <4.2.0.58.20010621091203.00cee190@pop3.norton.antivirus>

At 10:57 AM 6/21/2001 -0500, Patrick K. O'Brien wrote:
>Well, the current IDLE is 0.8. So any difference in the Shell
>capability between 0.5 and 0.8 are going to show up.

Absolutely.  But we're just comparing IDLE with itself --
it's not a whole other IDE/shell with VPython, like Pythonwin,
Boa or whatever.

I think ideally the standard IDLE will run user programs in
a different thread (what VPython's version does) and at that
point VPython might be able to stop doing a whole separate
IDLE.  That would seem an appropriate division of labor to
me (let the VPython team get out of the IDE business -- what
a recent post said was happening anyway, owing to time
constraints).  It was just extra work for them, to have to
go to the trouble of doing a separate version of IDLE.

I agree with Kurt B. Kaiser:  IDLE is great IDE to include
in the standard distro and there should *not* be some attempt
to rip out its guts in favor of some Scintilla-based thing
or whatever.  It's too far along, and works too well, to
be overhauled in such a fundamental way.  Tweek the key
bindings and some other things maybe.  Improve it
incrementally.  But don't overhaul from the ground up.

Too bad for Mac users that Tk is broken on that platform.
Maybe this will change with the newer UNIX-based OS?

I think at the heart of the issue is that Python, as a language,
is not GUI-centric, i.e. there's not GUI built in.  What you
have are wrapper/APIs around other languages for your GUI frames
and widgets, be that GNOME, Tk or Microsoft Foundation Classes
(Windows widgets).

In contrast, Java has its own native cross-platform AWT/Swing
classes, so it makes sense to write a Java IDE in pure Java.
The Java language isn't wrapping around something else (yes,
there are peer classes pairing the Java to platform-specific
implementations -- but this isn't the same thing (we're still
'thinking in Java' all the way down to button size and color)).

So when we talk Python IDE, we're talking Python + Something,
and there's no one other language that Python is "best" designed
to work with.  Because Python is ideally suited as a glue language,
which means, by definition, it gets along pretty well with a lot
of others.  So the "one way to do it" concept is coming up against
the "versatile glue language" concept, and I think in the case of
IDEs, it's the versatility that wins.

There's no reason to have just one IDE (certainly that's not
the case in Java world either, or many other worlds -- any
number (and they don't have shell mode because Java, like C,
like Pascal, is not interactive).  However, it is arguable
that there should be one IDE that ships standard with Python
under the same license agreement.  IDLE is currently that IDE,
and I think should continue in that role.

As for everyone standardizing on the same "right" IDE for
their own development work:  it ain't never going to happen,
nor should it.  IDLE is great for learning, has a bright
future in the classroom (where Python is catching on).  But
it doesn't need to be "the" IDE, even if it's the one that
ships as the default, as part of the standard distro (same
with Linux GUIs -- KDE, Gnome... there's no "one right
interface" there either).  It's only in the imperial paradigm
that we standardize at this level (closer to the Microsoft
model).

Kirby



From alan.gauld@bt.com  Thu Jun 21 17:33:22 2001
From: alan.gauld@bt.com (alan.gauld@bt.com)
Date: Thu, 21 Jun 2001 17:33:22 +0100
Subject: [Tutor] Re: [Edu-sig] RE: [Idle-dev] IDLE's save-before-run r
 equirement
Message-ID: <5104D4DBC598D211B5FE0000F8FE7EB20751D853@mbtlipnt02.btlabs.bt.co.uk>

> But IDLE has a bunch of requirements that I don't think Scintilla can
> provide.  

Possibly so, hence my comments about Scintilla being lumbered with an
extra customer to appease and reuse being expensive, but...

> is the Python Shell.  Compare editing an interactive session in
> PythonWin's console window with IDLE's Python Shell.  

I don't see much difference but confess to not using Pythonwin often 
- usually just for its superior debugger

> as the module/file editor, meaning you get 
> proper syntax coloring,

Seems OK to me

> automatic indentation,

Yes that works

> call tips, 

Yes,

> magic expansion; 

Wassat?

> you get per-line syntax checking, 

Not sure how that differs from PW

> whole-command editing, and 

And again wassat?

> history

Yes, got that too.

> recall.  In PythonWin's much more primitive console, it's very easy to
> mess up the input or the output or confuse the auto-indenter.

I can't say I've ever done that in eoither IDLE or PW but thats maybe 
again a reflection on how rarely I use PW...

> I could be wrong about Scintilla not supporting this, but if it did,
> why would PythonWin not use it for *its* console?

I think it does from what I see. It looks identical to a normal edit 
window to me...

Alan G

Note I'm on Python V2.0 with winall inbstalled not the ActiveState 
version in case that makes a difference.


From python.tutor@atrixnet.com  Thu Jun 21 21:11:48 2001
From: python.tutor@atrixnet.com (Tommy Butler)
Date: Thu, 21 Jun 2001 13:11:48 -0700
Subject: [Tutor] Re: [Edu-sig] RE: [Idle-dev] IDLE's save-before-run requirement
In-Reply-To: <5104D4DBC598D211B5FE0000F8FE7EB20751D853@mbtlipnt02.btlabs.bt.co.uk>
Message-ID: <NFBBKCNOILDDLKCLBNFIEEJCCFAA.python.tutor@atrixnet.com>

  >Note I'm on Python V2.0 with winall inbstalled not the ActiveState 
  >version in case that makes a difference.

Where can one get a hold of that?
I use the ActiveState version, but
would opt to use the oss version
if one exists and I could find it.

	-tommy


From MarkH@ActiveState.com  Fri Jun 22 02:29:56 2001
From: MarkH@ActiveState.com (Mark Hammond)
Date: Fri, 22 Jun 2001 11:29:56 +1000
Subject: [Tutor] Re: [Edu-sig] RE: [Idle-dev] IDLE's save-before-run r equirement
In-Reply-To: <200106211240.IAA30865@cj20424-a.reston1.va.home.com>
Message-ID: <LCEPIIGDJPKCOIHOBJEPIEPCEAAA.MarkH@ActiveState.com>

> I could be wrong about Scintilla not supporting this, but if it did,
> why would PythonWin not use it for *its* console?

Pythonwin does use scintilla for its console.  You are correct that it is
not integrated with the editor as tightly as IDLE.  This is mainly doe to
the fact pythonwin uses "... " as a secondary prompt, and also complications
with the scintilla lexer.

I agree that there would be significant work to get auto-indent and lexing
working correctly using scintilla as the console window.

As a "meta comment", over 12 months ago I added a feature to Pythonwin so
that new IDLE extensions could be used directly by both Pythonwin and IDLE.
In that time, not a single extra extension has been added (that I saw) and
IDLE changed its extension loading mechanism.

So while these things all sound good in theory, the reality is that people
need to actually _do_ it rather than speculate about how others could do it.
If we had a glut of new extensions being added to one environment and not
the other there would be a stronger case - but this simply isn't happening.
Witness the IDLE-fork project Guido mentioned - lots of talk, no action :(

Replying to Patrick's mail:

> What, if anything, can be
> done about this situation, or am I barking up the wrong tree?

You have 2 choices:  you can lobby for the various authors to make these
changes themselves, or you can submit patches to the authors.  I will let
you guess the most effective route :)  The commercial products may well do
it for "competitive advantage" reasons, or indeed they may _not_ do it for
exactly the same reasons!  The maintainers of the free software are likely
to be lacking any incentive, as their products generally work fine for them,
and probably have far more important things they could be doing (either for
free, or for their salary)

Mark.



From guido@digicool.com  Fri Jun 22 03:11:27 2001
From: guido@digicool.com (Guido van Rossum)
Date: Thu, 21 Jun 2001 22:11:27 -0400
Subject: Fwd: Re: [Tutor] [Edu-sig] [Idle-dev] IDLE's save-before-run requirement
In-Reply-To: Your message of "Fri, 22 Jun 2001 10:09:32 +1000."
 <01062202513904.01178@oberon.casa-guava.org>
References: <01062202513904.01178@oberon.casa-guava.org>
Message-ID: <200106220211.f5M2BSA05588@odiug.digicool.com>

Hi Stephen (what's your last name???).

Your plan sounds good to me.  You can be the project coordinator for
IDLE, and you keep me in the loop to help you decide on crucial
issues.

The list of things you want to do looks good except I'm not keen on
templates (I find them crutches).  Your first goal ought to be to get
the idle-fork project up to the same level as the current Python CVS
version of IDLE.  Then I can check in the "remote" options and you can
take it from there.

If you want to I can add you to the project admins right now, but I'd
like to wait a bit until I hear from David Scherer (who is the
originator).

David, I hope you're on this list!

--Guido van Rossum (home page: http://www.python.org/~guido/)


From guido@digicool.com  Fri Jun 22 03:12:19 2001
From: guido@digicool.com (Guido van Rossum)
Date: Thu, 21 Jun 2001 22:12:19 -0400
Subject: [Idle-dev] Re: IDLE's save-before-run r equirement
In-Reply-To: Your message of "Thu, 21 Jun 2001 10:40:01 CDT."
 <NBBBIOJPGKJEKIECEMCBKEDCKBAA.pobrien@orbtech.com>
References: <NBBBIOJPGKJEKIECEMCBKEDCKBAA.pobrien@orbtech.com>
Message-ID: <200106220212.f5M2CJa05601@odiug.digicool.com>

Patrick,

(You sent me a message in private but I'm replying in public since
others have brought up the same thing.)

I see that Pythonwin now is much better than the last time I used it.
Its console is indeed similar in functionality and robustness as
IDLE's.  (You can still make the "..." continuation prompt part of the
source text by accidentally hitting the delete key in the wrong place,
but that's rare.)

Regarding IDLE's key bindings, I hope that someone will do some work
on them.  They are really bad.  They should also be more easily
customizable...

And rather than choosing Emacs or Windows bindings based on platform,
that should be a user setting.  ETc.

--Guido van Rossum (home page: http://www.python.org/~guido/)


From tim.one@home.com  Fri Jun 22 04:16:10 2001
From: tim.one@home.com (Tim Peters)
Date: Thu, 21 Jun 2001 23:16:10 -0400
Subject: [Tutor] Re: [Edu-sig] RE: [Idle-dev] IDLE's save-before-run r equirement
In-Reply-To: <LCEPIIGDJPKCOIHOBJEPIEPCEAAA.MarkH@ActiveState.com>
Message-ID: <LNBBLJKPBEHFEDALKOLCKEOCKJAA.tim.one@home.com>

Wow -- this has a giant distribution list!  I'll play along <wink>.

[Mark Hammond]
> Pythonwin does use scintilla for its console.  You are correct that it
> is not integrated with the editor as tightly as IDLE.  This is mainly
> doe to the fact pythonwin uses "... " as a secondary prompt, and also
> complications with the scintilla lexer.

FWIW, I wish IDLE used "... " too -- switching between a DOS-box Python and
IDLE is jarring.  In addition, the IDLE shell uses hard tab characters stuck
at 8-space indents (the latter is a limitation of the Tk Text widget), while
all the other edit windows use no hard tab characters and 4-space indents.
So in a *typical* IDLE session (where I've also got a DOS-box Python
running), I'm dealing with three distinct code presentations.  I can't say
it's a physical burden <wink>, but somehow or other it is tiring!

> I agree that there would be significant work to get auto-indent
> and lexing working correctly using scintilla as the console window.

Worth shooting for, though:  *that* uniformity between shell and edit buffer
is very nice to have.

> As a "meta comment", over 12 months ago I added a feature to Pythonwin
> so that new IDLE extensions could be used directly by both Pythonwin
> and IDLE.  In that time, not a single extra extension has been added
> (that I saw) and IDLE changed its extension loading mechanism.
>
> So while these things all sound good in theory, the reality is that
> people need to actually _do_ it rather than speculate about how others
> could do it.

I'm not sure, Mark, but you and I may be the only two people in the History
of the Universe to actively cooperate on sharing code between two GUI
systems (the auto-indent system shared by PythonWin and IDLE).  It wasn't
that painful, but I recall being utterly unable to get anyone else
interested in playing with us at the time.  Since then, IDLE has stagnated
but remained useful, while you've gone on to fame and riches.  See?  There's
no payback to cooperation <wink>.



From jprobinson@oxford.gov.uk  Fri Jun 22 10:00:40 2001
From: jprobinson@oxford.gov.uk (ROBINSON Julian)
Date: Fri, 22 Jun 2001 10:00:40 +0100
Subject: [Tutor] [Edu-sig] [Idle-dev] IDLE's save-before-run requireme
 nt
Message-ID: <EE55ED92A316D411B59B009027DC722602A6DC93@exchangesrv.oxford.gov.uk>

This is a multi-part message in MIME format.
--------------InterScan_NT_MIME_Boundary
Content-Type: text/plain

> kbk@shore.net wrote
> 
> 4. Very usable by relatively inexperienced people.
> 
> IMHO IDLE should remain at roughly the (apparent) level of complexity it's
> at
> (or less?) to avoid reducing its usability for beginning/intermediate
> programmers.
> 
- As someone who's working through the tutorials IDLE is perfect. I don't
need a fancy
IDE to get the hang of the language. When I get enough experience to write
large programmes
then my need for an all singing & dancing IDE will increase, but until
then......
- The set-up for IDLE is easy, I managed to do it first time. I downloaded
JBuilder and this package took me ages to set up so that I could use it even
halfway properly, this has put me off 'getting into' Java. Whereas after
about 2 mins, following the clear instructions I was able to start entering
Python code and see how the language worked, and have never looked
back.......



--------------InterScan_NT_MIME_Boundary
Content-Type: text/plain;
	name="InterScan_Disclaimer.txt"
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment;
	filename="InterScan_Disclaimer.txt"

.
This email and any files transmitted with it are confidential and intended solely for the use of the individual to whom they are addressed.  
If you received this email in error please notify the sender by return email or contact Oxford City Council's IS dept. 01865-252111.
http://www.oxford.gov.uk
.

--------------InterScan_NT_MIME_Boundary--


From guido@digicool.com  Fri Jun 22 14:31:13 2001
From: guido@digicool.com (Guido van Rossum)
Date: Fri, 22 Jun 2001 09:31:13 -0400
Subject: [Tutor] Re: [Edu-sig] RE: [Idle-dev] IDLE's save-before-run r equirement
In-Reply-To: Your message of "Thu, 21 Jun 2001 23:16:10 EDT."
 <LNBBLJKPBEHFEDALKOLCKEOCKJAA.tim.one@home.com>
References: <LNBBLJKPBEHFEDALKOLCKEOCKJAA.tim.one@home.com>
Message-ID: <200106221331.f5MDVEP06120@odiug.digicool.com>

> [Mark Hammond]
> > Pythonwin does use scintilla for its console.  You are correct that it
> > is not integrated with the editor as tightly as IDLE.  This is mainly
> > doe to the fact pythonwin uses "... " as a secondary prompt, and also
> > complications with the scintilla lexer.
> 
> FWIW, I wish IDLE used "... " too -- switching between a DOS-box Python and
> IDLE is jarring.  In addition, the IDLE shell uses hard tab characters stuck
> at 8-space indents (the latter is a limitation of the Tk Text widget), while
> all the other edit windows use no hard tab characters and 4-space indents.
> So in a *typical* IDLE session (where I've also got a DOS-box Python
> running), I'm dealing with three distinct code presentations.  I can't say
> it's a physical burden <wink>, but somehow or other it is tiring!

Actually, I just downloaded and ran the latest Pythonwin available
without downloading ActivePython, and it has roughly the same
characteristics as IDLE: in its console window it uses hard tabs at 8
space distances, in its module editing it uses 4 spaces.  IDLE uses
the same defaults.

Regarding the "..." prompt: I happen to hate this, and in Pythonwin it
makes copying and pasting multi-line text from the console into a
module window a pain (you have to manually remove all the "...").

> > As a "meta comment", over 12 months ago I added a feature to Pythonwin
> > so that new IDLE extensions could be used directly by both Pythonwin
> > and IDLE.  In that time, not a single extra extension has been added
> > (that I saw) and IDLE changed its extension loading mechanism.

Yes, but the API that extensions have to conform to didn't change.
It's just the sad case that in the last 12 months *my* interest in (or
at least my ability to work on) IDLE has lapsed, for a variety of
reasons, and that may have affected others' interest -- until the
recent thread.

> > So while these things all sound good in theory, the reality is that
> > people need to actually _do_ it rather than speculate about how others
> > could do it.
> 
> I'm not sure, Mark, but you and I may be the only two people in the History
> of the Universe to actively cooperate on sharing code between two GUI
> systems (the auto-indent system shared by PythonWin and IDLE).  It wasn't
> that painful, but I recall being utterly unable to get anyone else
> interested in playing with us at the time.  Since then, IDLE has stagnated
> but remained useful, while you've gone on to fame and riches.  See?  There's
> no payback to cooperation <wink>.

:-)

--Guido van Rossum (home page: http://www.python.org/~guido/)


From pobrien@orbtech.com  Fri Jun 22 14:28:53 2001
From: pobrien@orbtech.com (Patrick K. O'Brien)
Date: Fri, 22 Jun 2001 08:28:53 -0500
Subject: Fwd: Re: [Tutor] [Edu-sig] [Idle-dev] IDLE's save-before-run requirement
In-Reply-To: <200106220211.f5M2BSA05588@odiug.digicool.com>
Message-ID: <NBBBIOJPGKJEKIECEMCBEEFGKBAA.pobrien@orbtech.com>

Where is the plan? I seem to have missed something here.

---
Patrick K. O'Brien
Orbtech
"I am, therefore I think."

-----Original Message-----
From: idle-dev-admin@python.org [mailto:idle-dev-admin@python.org]On Behalf
Of Guido van Rossum
Sent: Thursday, June 21, 2001 9:11 PM
To: stephen
Cc: idle-dev@python.org
Subject: Re: Fwd: Re: [Tutor] [Edu-sig] [Idle-dev] IDLE's save-before-run
requirement

Hi Stephen (what's your last name???).

Your plan sounds good to me.  You can be the project coordinator for
IDLE, and you keep me in the loop to help you decide on crucial
issues.

The list of things you want to do looks good except I'm not keen on
templates (I find them crutches).  Your first goal ought to be to get
the idle-fork project up to the same level as the current Python CVS
version of IDLE.  Then I can check in the "remote" options and you can
take it from there.

If you want to I can add you to the project admins right now, but I'd
like to wait a bit until I hear from David Scherer (who is the
originator).

David, I hope you're on this list!

--Guido van Rossum (home page: http://www.python.org/~guido/)

_______________________________________________
IDLE-dev mailing list
IDLE-dev@python.org
http://mail.python.org/mailman/listinfo/idle-dev



From dscherer@vysics.com  Fri Jun 22 17:04:36 2001
From: dscherer@vysics.com (David Scherer)
Date: Fri, 22 Jun 2001 12:04:36 -0400
Subject: Fwd: Re: [Tutor] [Edu-sig] [Idle-dev] IDLE's save-before-run requirement
In-Reply-To: <200106220211.f5M2BSA05588@odiug.digicool.com>
Message-ID: <000f01c0fb35$09069a40$8101a8c0@RABBIT>

Hi all!

I have no objection whatsoever to giving someone else idle-fork.  The
sourceforge project was created *after* I had mostly stopped active work
on my enhancements to IDLE, so that *other* people could contribute.
Here's what I said last year:

> Sent: Thursday, August 10, 2000 1:43 PM
>
> On Thu, 10 Aug 2000, Guido van Rossum wrote:
> 
> > What happened to the idea of producing a (temporary?) fork 
> of IDLE at 
> > SourceForge to get more people to work on these things?
> > 
> > I can't offer to participate, but I don't want to stifle 
> development 
> > either!
> 
> As I recall, I made the suggestion and you volunteered me to 
> do it :) Unfortunately, I didn't have the spare cycles at the time.
> 
> I've started the process of creating a sourceforge project, 
> and I'll upload my version of IDLE into CVS once it exists.  
> However, I don't currently have time to do much work on IDLE 
> either, so I hope other people are interested in being 
> developers.  I will give anyone who asks developer or admin access.

I think that pretty much states my position now, as well.  Enjoy!

(Some things to keep in mind: the largest difference between idle-fork
and the mainstream IDLE of the time was the addition of remote process
functionality similar to what Guido discussed.  It doesn't have quite as
gaping a security hole, because the client process makes a connection to
IDLE instead of the other way around, but I can't make any unequivocal
guarantees about its security on a multi-user box.  In any case, if you
are planning on checking Guido's code in, you will have to remove mine!)

Dave

> -----Original Message-----
> From: idle-dev-admin@python.org 
> [mailto:idle-dev-admin@python.org] On Behalf Of Guido van Rossum
> Sent: Thursday, June 21, 2001 10:11 PM
> To: stephen
> Cc: idle-dev@python.org
> Subject: Re: Fwd: Re: [Tutor] [Edu-sig] [Idle-dev] IDLE's 
> save-before-run requirement
> 
> 
> Hi Stephen (what's your last name???).
> 
> Your plan sounds good to me.  You can be the project 
> coordinator for IDLE, and you keep me in the loop to help you 
> decide on crucial issues.
> 
> The list of things you want to do looks good except I'm not 
> keen on templates (I find them crutches).  Your first goal 
> ought to be to get the idle-fork project up to the same level 
> as the current Python CVS version of IDLE.  Then I can check 
> in the "remote" options and you can take it from there.
> 
> If you want to I can add you to the project admins right now, 
> but I'd like to wait a bit until I hear from David Scherer 
> (who is the originator).
> 
> David, I hope you're on this list!
> 
> --Guido van Rossum (home page: http://www.python.org/~guido/)
> 
> _______________________________________________
> IDLE-dev mailing list
> IDLE-dev@python.org http://mail.python.org/mailman/listinfo/idle-dev
> 



From guido@digicool.com  Fri Jun 22 17:37:15 2001
From: guido@digicool.com (Guido van Rossum)
Date: Fri, 22 Jun 2001 12:37:15 -0400
Subject: Re [Idle-dev] IDLE's save-before-run requirement
In-Reply-To: Your message of "Fri, 22 Jun 2001 12:04:36 EDT."
 <000f01c0fb35$09069a40$8101a8c0@RABBIT>
References: <000f01c0fb35$09069a40$8101a8c0@RABBIT>
Message-ID: <200106221637.f5MGbG406922@odiug.digicool.com>

> I have no objection whatsoever to giving someone else idle-fork.  The
> sourceforge project was created *after* I had mostly stopped active work
> on my enhancements to IDLE, so that *other* people could contribute.

Thanks, David.  I've added Stephen.  (Stephen, if you would update
your SF personal info to include your last name I'd appreciate it.  In
the Python development world a first name is often not enough to
uniquely identify a person.  :-)

> (Some things to keep in mind: the largest difference between idle-fork
> and the mainstream IDLE of the time was the addition of remote process
> functionality similar to what Guido discussed.  It doesn't have quite as
> gaping a security hole, because the client process makes a connection to
> IDLE instead of the other way around, but I can't make any unequivocal
> guarantees about its security on a multi-user box.  In any case, if you
> are planning on checking Guido's code in, you will have to remove mine!)

Understood.  I'll probably give my changes (which are just three new
files pluss diffs to a fourth) to Stephen for consolidation.  I think
the main change that needs to be made to make it safer is that the
parent process (IDLE) should listen for a connection and the
subprocess that executes the commands should connect to the parent.
It is currently the other way around, which is unsafe.  Additional
safety measures should also be taken, but I believe this reversal of
roles is essential.

--Guido van Rossum (home page: http://www.python.org/~guido/)


From elguavas@users.sourceforge.net  Sat Jun 23 01:47:56 2001
From: elguavas@users.sourceforge.net (stephen)
Date: Sat, 23 Jun 2001 10:47:56 +1000
Subject: Fwd: Re: [Tutor] [Edu-sig] [Idle-dev] IDLE's save-before-run requirement
In-Reply-To: <200106220150.f5M1oN805429@odiug.digicool.com>
References: <01062202513904.01178@oberon.casa-guava.org> <200106220150.f5M1oN805429@odiug.digicool.com>
Message-ID: <01062214290300.01671@oberon.casa-guava.org>

Hello IDLERs,
sorry if this thread got a little confused by a couple of missing messages, I 
wasn't noticing that a couple of my replies were going back to the original 
sender but not cc'ing to idle-dev. Here's the most recent and relevant 
message from me to Guido on revitalising the  idle-fork project.

Folks, basically it was to keep IDLE on track with Guido as leader, ultimate 
arbiter of destiny, while I try to take on a coordinator (and I hope, more 
interestingly, contributing  coder and doc writer) role to free up Guido's 
day to day time as he needs for (doubtless many) other things. I think the 
gist of what I originally wrote to him was summed up in:  "Anyway the major 
points of my proposal are: steady as she goes, and, to keep your hand on the 
reins, while freeing it as much as you need."  I'll post the relevant parts 
of the whole message to idle-dev when I get a chanceto dig it out from my 
other machine.

-------- Forwarded message ------------
Hi again Guido,

On Fri, 22 Jun 2001 11:50am, you wrote:
> Hi Stephen (what's your last name???).

Oh, Stephen M. Gava, that's me. I used to get called 'guava' a lot when I was 
a kid, and then 'esteban' (short for 'esteban guava') by co-workers some 
years later, so my usual email tag is 'elguavas' ( as in el guava s. ). I 
usually use that email account (elguavas@sourceforge.net) with friends, who 
know my full name, and for support of pyChing and pyWings, both of which have 
my full names in the about box contact details. I'll fix up my tagline and 
sourceforge details so that info is clear for this account.

> Your plan sounds good to me.  You can be the project coordinator for
> IDLE, and you keep me in the loop to help you decide on crucial
> issues.

Well that's great, I accept, and hope I can do a good job. Time to start 
getting up to speed on a few things I guess.

> The list of things you want to do looks good except I'm not keen on
> templates (I find them crutches).  

Ok, that's fine, and I see your point there. Those coding suggestions were 
really just off the top of my tired head.  I think the ability to somehow 
easily/automaticall look up relevant python documentation from the editor 
(context help), would be much more useful (and much better for learning too), 
but I think out of the things I suggested this would be the hardest to 
implement, or at least the one where I have the least idea how to start 
anyway. But these things in good time I guess.

> Your first goal ought to be to get
> the idle-fork project up to the same level as the current Python CVS
> version of IDLE.  Then I can check in the "remote" options and you can
> take it from there.

Ok, so you think proceeding with, revitalising, the existing idle-fork 
project is the best way to work on improved idle? That makes sense to me too. 
It means we have some scope to play with "developer versions" (within reason) 
without upsetting stable idle, a way of seeing what works or not for future 
merging, as intended.

> If you want to I can add you to the project admins right now, but I'd
> like to wait a bit until I hear from David Scherer (who is the
> originator).

Please do this. I have no desire to be inadvertently stepping on anyones toes 
at all. I merely want to offer my time to this, that I consider worthy task. 

> David, I hope you're on this list!

Me too. If he still wants to be involved that would be great. I need to soon 
work out some of who will be useful help for which things.

Stephen.
-- 
Stephen M. Gava
<elguavas@users.sourceforge.net>
More power to those who don't care for it.



From elguavas@users.sourceforge.net  Sat Jun 23 02:37:06 2001
From: elguavas@users.sourceforge.net (stephen)
Date: Sat, 23 Jun 2001 11:37:06 +1000
Subject: Fwd: Re: [Tutor] Re: [Edu-sig] RE: [Idle-dev] IDLE's save-before-run r equirement
Message-ID: <01062311370601.01173@oberon.casa-guava.org>

Ok, as mentioned in my last message, here are the idle-dev related parts of 
my original message to Guido on revitalising IDLE; for historical 
edification. 

----------  Forwarded Message  ----------
Subject: Re: [Tutor] Re: [Edu-sig] RE: [Idle-dev] IDLE's save-before-run r 
equirement
Date: Fri, 22 Jun 2001 02:16:18 +1000
From: stephen <elguavas@users.sourceforge.net>
To: Guido van Rossum <guido@digicool.com>

On Fri, 22 Jun 2001 12:48am, you wrote:
> Thanks for your long and well-reasoned reply.
> Do you mind if I resend that to the idle-sig?
>> > I just did that, moments after I accidentally sent it only to you... 8-\
>
> Noticed.
>
> > Actually, I have a proposal for you on the future of IDLE, which I'd like
> > to run by you.
>
> Sure!

Great. I've actually been thinking quite a lot about this.
[...]
In any case, I'd better _try_ and be brief so here are a few of my ideas 
about IDLE in  disorganised, after 1am, point(ish) form:

1. IDLE needs a benevolent dictator (and I think it should be you :).
I've been involved in other open source projects with pretty open cvs and
an insane level of 'democracy'. Those projects were washouts that ended
up getting nowherere by not getting everywhere. Sure people need to be able to
have a say. But we need a clear statement of what IDLE is and will remain
that any contributors can work to. I'd like to see that 'mission statement'
being something that includes things along the lines of the points I was
trying to make in my pervious message to the list, and that have since been 
stated more clearly by many others, about IDLE staying on track. Of course 
this needs to be flexible enough to allow growth.

2. You are obviously way to busy to be a fully hands on leader of a
revitalised IDLE project, so you need a 'coordinator', that is
someone to isolate you from a lot of stuff so your input can be on the
important issues plus whatever else you feel like and have the time for
lending your hand to. But I think it would be important for you to retain
final power of veto, or 'weight of opinnion' if you prefer, over changes and
the direction of the project just like you do over the rest of python.

I think you'd like to retain your influence over IDLE, and I think it would 
be best if you did. I'm sure it's only as neat as it is now because you've 
been caring for it. ;-)

Anyway, I have the inclination, and I'd like to make the time available to
take on this job. All I have to offer are modest python and tkinter 
experience,  and some ability to write documentation (which I've done before),
a generally reasonable temper, and some enthusiasm for the task. Of course I 
don't expect anything to happen because of this, I'm just offering.

3. Some of the things I would propose doing:

Revitalise the hosting of the IDLE development project; site it somewhere 
(where it already is?), have the code in cvs with only limited committers: 
any code donations accepted of course but by patch, to be assessed and merged 
if appropriate by those who can commit. Checkouts carte blanche, snapshots as 
appropriate. More stuff on the website, including the mission statement and a 
faq with info for those who want to submit patches or help out in other ways. 
etc. Look into merging what is decided upon from the Vpython and the exiting 
fork project at sourceforge.

The things I'd like to work on personally (at least some of):
1. coordination and filtering stuff for you attention as required (up to your
time available, etc.).
2. coding
- a) making the inteface nicer in terms of gui configurability for fonts,
colours, recent files list, etc. etc. (iI like doing this kind of user
friendly stuff )
- b) maybe code template insertion (for language keywords, etc)?? or context 
help lookup (from code in editor) to python documentation for langage element 
and library stuff?
(- ( c) slightly possibly at some stage  looking into completing some half 
baked early stage work on a simple python coded tkinter gui - builder I 
started once, as an optional add on) ??)
3. writing a new section of standard python documentation on IDLE, to make
IDLE really a noticed part of python and for use as the IDLE help also.
4. canvassing edu-sig guys for input into how to make IDLE better for helping
python learners.

Hmm, that already seems like a lot... and I'm sure there were other ideas 
that I'm not thinking of right now. 8-\

Anyway, sorry to take up so much of your time with all this. Let me know what 
you think about any of these ideas. I'm offering the time and energy for any 
of this that you think is worthwhile (maybe none! :), I'll certainly give a 
try if it would be any use.

BTW, what I notice appearing on the idle-dev list about it really being
'compatability'  problem between various ide's can of course all be 
solved by a combination of configurability in IDLE and enabling some 
behaviours by command line switches etc., of desired. No need to throw out 
all the good work in IDLE to help with the kinds of issues mentionned here.

Anyway the major points of my proposal are: steady as she goes, and, to keep
your hand on the reins, while freeing it as much as you need.

Regards,
Stephen.
ps. apologies for tired typos and spelling.
--
<elguavas@users.sourceforge.net>
More power to those who don't care for it.

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

-- 
Stephen M. Gava
<elguavas@users.sourceforge.net>
"More power to those who don't care for it." - anon


From StephenM.Gava  Sat Jun 23 05:25:13 2001
From: StephenM.Gava (StephenM.Gava)
Date: Sat, 23 Jun 2001 14:25:13 +1000
Subject: [Idle-dev] idle-fork odds and ends
Message-ID: <01062314251302.01173@oberon.casa-guava.org>

Hello all,
as you may have noticed in recent messages on this list GvR has decided that 
the idle-fork project at sourceforge will be revitalised as the place for 
working on ongoing improvement of IDLE, to be mereged into stable IDLE when 
and if appropriate. Thanks to David Scherer (initiator of idle-fork) handing 
over the role (due to not having sufficient time to devote at present) I'm 
going to attempt to coordinate the project there, with Guido remaining as 
lord high poobah, and contributor as much as his time allows. 

I suggest that future posts to this list related specifically to idle-fork 
have "idle-fork" somewhere in the subject, to make it easier for mail 
filtering etc. 

The first thing we are going to do is bring idle-fork up to date by merging 
python-idle-cvs and Guido's 'run in a seperate process' patches into it, so 
until that's completed idle-fork's own cvs won't be much use to anyone. I'll 
notify this list directly upon a meaningful idle-fork cvs being available 
again. I'll post here again soon with a list of things we are going to move 
onto first after that.

Now a few odds and ends from recent messages here
(time order, oldest first):

> Where is the plan? I seem to have missed something here.

Apologies for stuffing up my posting here. See my previous couple of messages 
in the thread  "Fwd: Re: [Tutor] Re: [Edu-sig] RE: [Idle-dev] IDLE's 
save-before-run r equirement" for the background.

> Regarding IDLE's key bindings, I hope that someone will do some work
> on them.  They are really bad.  They should also be more easily
> customizable...
>
> And rather than choosing Emacs or Windows bindings based on platform,
> that should be a user setting.  ETc.

This is on the agenda.

> I think that pretty much states my position now, as well.  Enjoy!

Thanks David... I hope!   {-\

> David, I've added Stephen.  (Stephen, if you would update
> your SF personal info to include your last name I'd appreciate it.  In
> the Python development world a first name is often not enough to
> uniquely identify a person.  :-)

Done. :-)

> Understood.  I'll probably give my changes (which are just three new
> files pluss diffs to a fourth) to Stephen for consolidation.  I think
> the main change that needs to be made to make it safer is that the
> parent process (IDLE) should listen for a connection and the
> subprocess that executes the commands should connect to the parent.
> It is currently the other way around, which is unsafe.  Additional
> safety measures should also be taken, but I believe this reversal of
> roles is essential.

David, if you have even the teeniest amount of time available, or could 
recommend someone who's up on the topic  this is one of the things I would 
appreciate some help on. (Any other volunteers for this?)

Ok, time to make saturday lunch for my kids,
cheers,
Stephen.
-- 
Stephen M. Gava
<elguavas@users.sourceforge.net>
"More power to those who don't care for it." - anon


From pobrien@orbtech.com  Sat Jun 23 15:15:36 2001
From: pobrien@orbtech.com (Patrick K. O'Brien)
Date: Sat, 23 Jun 2001 09:15:36 -0500
Subject: [Tutor] [Edu-sig] [Idle-dev] IDLE's save-before-run requirement
In-Reply-To: <01062214290300.01671@oberon.casa-guava.org>
Message-ID: <NBBBIOJPGKJEKIECEMCBKEHBKBAA.pobrien@orbtech.com>

Stephen,

Thank you for finding the missing messages and posting them. And thank you
for volunteering to help coordinate the IDLE revitilization (lather, rinse,
repeat?). I think this final result is a very good thing. I wish you, Guido
and everyone else the best of luck and look forward to helping out to the
extent that I am able. Steady as she goes...

---
Patrick K. O'Brien
Orbtech
"I am, therefore I think."

-----Original Message-----
From: idle-dev-admin@python.org [mailto:idle-dev-admin@python.org]On Behalf
Of stephen
Sent: Friday, June 22, 2001 7:48 PM
To: idle-dev@python.org
Subject: Fwd: Re: [Tutor] [Edu-sig] [Idle-dev] IDLE's save-before-run
requirement

Hello IDLERs,
sorry if this thread got a little confused by a couple of missing messages,
I
wasn't noticing that a couple of my replies were going back to the original
sender but not cc'ing to idle-dev. Here's the most recent and relevant
message from me to Guido on revitalising the  idle-fork project.

Folks, basically it was to keep IDLE on track with Guido as leader, ultimate
arbiter of destiny, while I try to take on a coordinator (and I hope, more
interestingly, contributing  coder and doc writer) role to free up Guido's
day to day time as he needs for (doubtless many) other things. I think the
gist of what I originally wrote to him was summed up in:  "Anyway the major
points of my proposal are: steady as she goes, and, to keep your hand on the
reins, while freeing it as much as you need."  I'll post the relevant parts
of the whole message to idle-dev when I get a chanceto dig it out from my
other machine.



From dscherer@vysics.com  Sat Jun 23 19:41:05 2001
From: dscherer@vysics.com (David Scherer)
Date: Sat, 23 Jun 2001 14:41:05 -0400
Subject: [Idle-dev] RE: idle-fork odds and ends
In-Reply-To: <01062314251302.01173@oberon.casa-guava.org>
Message-ID: <000101c0fc14$0fe84680$8101a8c0@RABBIT>

> > Understood.  I'll probably give my changes (which are just 
> three new 
> > files pluss diffs to a fourth) to Stephen for 
> consolidation.  I think 
> > the main change that needs to be made to make it safer is that the 
> > parent process (IDLE) should listen for a connection and the 
> > subprocess that executes the commands should connect to the 
> parent. It 
> > is currently the other way around, which is unsafe.  
> Additional safety 
> > measures should also be taken, but I believe this reversal 
> of roles is 
> > essential.
> 
> David, if you have even the teeniest amount of time 
> available, or could 
> recommend someone who's up on the topic  this is one of the 
> things I would 
> appreciate some help on. (Any other volunteers for this?)

I have enough time to answer questions, at least.  I haven't seen
Guido's source, so I can't comment on it.  I can tell you the following
about the code currently in idle-fork:

(1) My implementation of "remote process execution" already works the
way Guido wants: IDLE listens for a connection, then spawns a subprocess
which connects back to IDLE.  This makes it unlikely that an attacker
will be able to connect to the subprocess, although they may be able to
connect to IDLE.  However, my implementation probably isn't secure,
because:

(2) My implementation uses a simple RPC protocol implemented in
protocol.py for communication in both directions.  I took this approach
over simple I/O redirection because I imagined that eventually debugging
functionality would be desired, and RPC would make implementing that
vastly easier.  Since the subprocess can make RPC calls into IDLE,
making IDLE the server doesn't really help.

(3) It seems to me that making the connection between IDLE and its
subprocess in a secure way is a much better solution than trying to make
the protocol itself secure.  I think this is normally done by creating
both the client and server ends of the connection in IDLE, and passing
one end to the subprocess during its creation.  However, I'm not sure
that can be done in a cross-platform way.

Let me know what else you want to know.



From StephenM.Gava  Sun Jun 24 02:32:45 2001
From: StephenM.Gava (StephenM.Gava)
Date: Sun, 24 Jun 2001 11:32:45 +1000
Subject: [Tutor] [Edu-sig] [Idle-dev] IDLE's save-before-run requirement
In-Reply-To: <NBBBIOJPGKJEKIECEMCBKEHBKBAA.pobrien@orbtech.com>
References: <NBBBIOJPGKJEKIECEMCBKEHBKBAA.pobrien@orbtech.com>
Message-ID: <01062411324500.01175@oberon.casa-guava.org>

> Stephen,
>
> Thank you for finding the missing messages and posting them. And thank you
> for volunteering to help coordinate the IDLE revitilization (lather, rinse,
> repeat?). 

Hey, now it's so shiny!  Actually, reading back I wish I had a dollar for 
every time the word 'revitalise' popped up in recent messages.   *L*

> I think this final result is a very good thing. I wish you, Guido
> and everyone else the best of luck and look forward to helping out to the
> extent that I am able. Steady as she goes...

Thanks. All help welcome, plus, once the dust settles from the initial stages 
(mainly merging cvs's, and me getting a handle on a fair few things) I'll try 
to get up a list of things interested parties could have a go at.

>
> ---
> Patrick K. O'Brien
> Orbtech
> "I am, therefore I think."
>
> -----Original Message-----
> From: idle-dev-admin@python.org [mailto:idle-dev-admin@python.org]On Behalf
> Of stephen
> Sent: Friday, June 22, 2001 7:48 PM
> To: idle-dev@python.org
> Subject: Fwd: Re: [Tutor] [Edu-sig] [Idle-dev] IDLE's save-before-run
> requirement
>
> Hello IDLERs,
> sorry if this thread got a little confused by a couple of missing messages,
> I
> wasn't noticing that a couple of my replies were going back to the original
> sender but not cc'ing to idle-dev. Here's the most recent and relevant
> message from me to Guido on revitalising the  idle-fork project.
>
> Folks, basically it was to keep IDLE on track with Guido as leader,
> ultimate arbiter of destiny, while I try to take on a coordinator (and I
> hope, more interestingly, contributing  coder and doc writer) role to free
> up Guido's day to day time as he needs for (doubtless many) other things. I
> think the gist of what I originally wrote to him was summed up in:  "Anyway
> the major points of my proposal are: steady as she goes, and, to keep your
> hand on the reins, while freeing it as much as you need."  I'll post the
> relevant parts of the whole message to idle-dev when I get a chanceto dig
> it out from my other machine.
>
>
> _______________________________________________
> IDLE-dev mailing list
> IDLE-dev@python.org
> http://mail.python.org/mailman/listinfo/idle-dev

-- 
Stephen M. Gava
<elguavas@users.sourceforge.net>
"More power to those who don't care for it." - anon


From StephenM.Gava  Sun Jun 24 02:51:25 2001
From: StephenM.Gava (StephenM.Gava)
Date: Sun, 24 Jun 2001 11:51:25 +1000
Subject: [Idle-dev] RE: idle-fork odds and ends
In-Reply-To: <000101c0fc14$0fe84680$8101a8c0@RABBIT>
References: <000101c0fc14$0fe84680$8101a8c0@RABBIT>
Message-ID: <01062411512501.01175@oberon.casa-guava.org>

> > > Understood.  I'll probably give my changes (which are just
> >  > three new
> > > files pluss diffs to a fourth) to Stephen for
> > > consolidation.  I think
> > > the main change that needs to be made to make it safer is that the
> > > parent process (IDLE) should listen for a connection and the
> > > subprocess that executes the commands should connect to the
> > > parent. It
> > > is currently the other way around, which is unsafe.
> > > Additional safety
> > > measures should also be taken, but I believe this reversal
> > > of roles is essential.
> >
> > David, if you have even the teeniest amount of time
> > available, or could
> > recommend someone who's up on the topic  this is one of the
> > things I would  appreciate some help on. 
> > (Any other volunteers for this?)
>
> I have enough time to answer questions, at least.  I haven't seen
> Guido's source, so I can't comment on it.  I can tell you the following
> about the code currently in idle-fork:
>
> (1) My implementation of "remote process execution" already works the
> way Guido wants: IDLE listens for a connection, then spawns a subprocess
> which connects back to IDLE.  This makes it unlikely that an attacker
> will be able to connect to the subprocess, although they may be able to
> connect to IDLE.  However, my implementation probably isn't secure,
> because:
>
> (2) My implementation uses a simple RPC protocol implemented in
> protocol.py for communication in both directions.  I took this approach
> over simple I/O redirection because I imagined that eventually debugging
> functionality would be desired, and RPC would make implementing that
> vastly easier.  Since the subprocess can make RPC calls into IDLE,
> making IDLE the server doesn't really help.
>
> (3) It seems to me that making the connection between IDLE and its
> subprocess in a secure way is a much better solution than trying to make
> the protocol itself secure.  I think this is normally done by creating
> both the client and server ends of the connection in IDLE, and passing
> one end to the subprocess during its creation.  However, I'm not sure
> that can be done in a cross-platform way.

I see,  thanks for this info. I've just started pouring over the full IDLE 
source, trying to build an overview of where everything fits.

> Let me know what else you want to know.

Will do. I'm still thinking that this is an area where, once changes have 
been merged and Guido has decided what he's doing with his code for this, 
I'll be looking for someone who wants to work on perfecting this as a 
priority. It's obviously a crucial improvement in IDLE, but not one I'd like 
to be doing the coding for myself, among the other things I'm hoping to take 
on,  if I can possibly avoid it. (But if I can't s'ok, I'l just put some 
other things on hold.)

-- 
Stephen M. Gava
<elguavas@users.sourceforge.net>
"More power to those who don't care for it." - anon


From StephenM.Gava  Sun Jun 24 05:56:41 2001
From: StephenM.Gava (StephenM.Gava)
Date: Sun, 24 Jun 2001 14:56:41 +1000
Subject: [Idle-dev] idle-fork cvs update notification via syncmail
Message-ID: <01062414564100.02082@oberon.casa-guava.org>

I've just updated the cvs administrative setup for the idlefork project so 
that it uses syncmail to automatically send out emil updates of cvs activity, 
like the python cvs does. 

At the moment I've got idle-dev set up as the target for these emails, so if 
you start seeng messages here titled something like "CVS: idle 
somefile.py,x.x"  (with a first line of "Update of /cvsroot/idlefork/idle" 
which indicates the update is on idle-fork), you can safely ignore them if 
you're not interested in every teensy detail of what's happenning in idlefork 
cvs.

If these cvs notices become a bother for listeners on this list we'll create 
a seperate "idlefork-commits" list at python.org for them.
-- 
Stephen M. Gava
<elguavas@users.sourceforge.net>
"More power to those who don't care for it." - anon


From elguavas@users.sourceforge.net  Sun Jun 24 06:10:43 2001
From: elguavas@users.sourceforge.net (Stephen)
Date: Sat, 23 Jun 2001 22:10:43 -0700
Subject: [Idle-dev] CVS: idle IDLEFORK.html,1.4,1.5
Message-ID: <E15E2AV-000509-00@usw-pr-cvs1.sourceforge.net>

Update of /cvsroot/idlefork/idle
In directory usw-pr-cvs1:/tmp/cvs-serv19219

Modified Files:
	IDLEFORK.html 
Log Message:
tiny change to test new syncmail setup

Index: IDLEFORK.html
===================================================================
RCS file: /cvsroot/idlefork/idle/IDLEFORK.html,v
retrieving revision 1.4
retrieving revision 1.5
diff -C2 -r1.4 -r1.5
*** IDLEFORK.html	2001/06/24 04:41:41	1.4
--- IDLEFORK.html	2001/06/24 05:10:41	1.5
***************
*** 17,21 ****
  This project is an official experimental development fork of <a
  href="http://www.python.org">Python</a>'s small, light, 'bundled' integrated development environment
! IDLE. Changes to this  version that are approved by Python's benevolent dictator for
  life will go back into the stable distribution version.
  
--- 17,21 ----
  This project is an official experimental development fork of <a
  href="http://www.python.org">Python</a>'s small, light, 'bundled' integrated development environment
! IDLE. <br>Changes to this  version that are approved by Python's benevolent dictator for
  life will go back into the stable distribution version.
  



From elguavas@users.sourceforge.net  Mon Jun 25 03:41:52 2001
From: elguavas@users.sourceforge.net (Stephen)
Date: Sun, 24 Jun 2001 19:41:52 -0700
Subject: [Idle-dev] CVS: official-idle - Imported sources
Message-ID: <E15EMK0-0001DB-00@usw-pr-cvs1.sourceforge.net>

Update of /cvsroot/idlefork/official-idle
In directory usw-pr-cvs1:/tmp/cvs-serv4611

Log Message:
importing from python cvs official idle

Status:

Vendor Tag:	python-cvs
Release Tags:	official-idle_1
		
N official-idle/idle
N official-idle/AutoIndent.py
N official-idle/ParenMatch.py
N official-idle/PathBrowser.py
N official-idle/keydefs.py
N official-idle/config-unix.txt
N official-idle/RemoteInterp.py
N official-idle/FileList.py
N official-idle/IOBinding.py
N official-idle/TODO.txt
N official-idle/testcode.py
N official-idle/MultiScrolledLists.py
N official-idle/ClassBrowser.py
N official-idle/ScrolledList.py
N official-idle/MultiStatusBar.py
N official-idle/SearchEngine.py
N official-idle/CallTips.py
N official-idle/OldStackViewer.py
N official-idle/ScriptBinding.py
N official-idle/WidgetRedirector.py
N official-idle/Percolator.py
N official-idle/NEWS.txt
N official-idle/Delegator.py
N official-idle/WindowList.py
N official-idle/config-win.txt
N official-idle/config.txt
N official-idle/PyShell.py
N official-idle/GrepDialog.py
N official-idle/OutputWindow.py
N official-idle/idle.bat
N official-idle/idle.pyw
N official-idle/SearchDialogBase.py
N official-idle/EditorWindow.py
N official-idle/UndoDelegator.py
N official-idle/eventparse.py
N official-idle/idlever.py
N official-idle/AutoExpand.py
N official-idle/Debugger.py
N official-idle/ColorDelegator.py
N official-idle/IdleHistory.py
N official-idle/README.txt
N official-idle/FrameViewer.py
N official-idle/SearchBinding.py
N official-idle/StackViewer.py
N official-idle/extend.txt
N official-idle/CallTipWindow.py
N official-idle/idle.py
N official-idle/setup.py
N official-idle/ZoomHeight.py
N official-idle/ObjectBrowser.py
N official-idle/PyParse.py
N official-idle/ToolTip.py
N official-idle/ReplaceDialog.py
N official-idle/IdleConf.py
N official-idle/FormatParagraph.py
N official-idle/__init__.py
N official-idle/SearchDialog.py
N official-idle/ChangeLog
N official-idle/TreeWidget.py
N official-idle/help.txt
N official-idle/Bindings.py
N official-idle/Separator.py
N official-idle/Icons/plusnode.gif
N official-idle/Icons/openfolder.gif
N official-idle/Icons/python.gif
N official-idle/Icons/folder.gif
N official-idle/Icons/tk.gif
N official-idle/Icons/minusnode.gif

No conflicts created by this import


***** Bogus filespec: -
***** Bogus filespec: Imported
***** Bogus filespec: sources


From elguavas@users.sourceforge.net  Mon Jun 25 07:59:14 2001
From: elguavas@users.sourceforge.net (Stephen)
Date: Sun, 24 Jun 2001 23:59:14 -0700
Subject: [Idle-dev] CVS: idle - Imported sources
Message-ID: <E15EQL4-0004ed-00@usw-pr-cvs1.sourceforge.net>

Update of /cvsroot/idlefork/idle
In directory usw-pr-cvs1:/tmp/cvs-serv17816

Log Message:
import current python cvs idle

Status:

Vendor Tag:	PYTHON_CVS
Release Tags:	IMPORT_1
		
N idle/idle/idle
N idle/idle/AutoIndent.py
N idle/idle/ParenMatch.py
N idle/idle/PathBrowser.py
N idle/idle/keydefs.py
N idle/idle/config-unix.txt
N idle/idle/RemoteInterp.py
N idle/idle/FileList.py
N idle/idle/IOBinding.py
N idle/idle/TODO.txt
N idle/idle/testcode.py
N idle/idle/MultiScrolledLists.py
N idle/idle/ClassBrowser.py
N idle/idle/ScrolledList.py
N idle/idle/MultiStatusBar.py
N idle/idle/SearchEngine.py
N idle/idle/CallTips.py
N idle/idle/OldStackViewer.py
N idle/idle/ScriptBinding.py
N idle/idle/WidgetRedirector.py
N idle/idle/Percolator.py
N idle/idle/NEWS.txt
N idle/idle/Delegator.py
N idle/idle/WindowList.py
N idle/idle/config-win.txt
N idle/idle/config.txt
N idle/idle/PyShell.py
N idle/idle/GrepDialog.py
N idle/idle/OutputWindow.py
N idle/idle/idle.bat
N idle/idle/idle.pyw
N idle/idle/SearchDialogBase.py
N idle/idle/EditorWindow.py
N idle/idle/UndoDelegator.py
N idle/idle/eventparse.py
N idle/idle/idlever.py
N idle/idle/AutoExpand.py
N idle/idle/Debugger.py
N idle/idle/ColorDelegator.py
N idle/idle/IdleHistory.py
N idle/idle/README.txt
N idle/idle/FrameViewer.py
N idle/idle/SearchBinding.py
N idle/idle/StackViewer.py
N idle/idle/extend.txt
N idle/idle/CallTipWindow.py
N idle/idle/idle.py
N idle/idle/setup.py
N idle/idle/ZoomHeight.py
N idle/idle/ObjectBrowser.py
N idle/idle/PyParse.py
N idle/idle/ToolTip.py
N idle/idle/ReplaceDialog.py
N idle/idle/IdleConf.py
N idle/idle/FormatParagraph.py
N idle/idle/__init__.py
N idle/idle/SearchDialog.py
N idle/idle/ChangeLog
N idle/idle/TreeWidget.py
N idle/idle/help.txt
N idle/idle/Bindings.py
N idle/idle/Separator.py
N idle/idle/Icons/plusnode.gif
N idle/idle/Icons/openfolder.gif
N idle/idle/Icons/python.gif
N idle/idle/Icons/folder.gif
N idle/idle/Icons/tk.gif
N idle/idle/Icons/minusnode.gif

No conflicts created by this import


***** Bogus filespec: -
***** Bogus filespec: Imported
***** Bogus filespec: sources


From elguavas@users.sourceforge.net  Mon Jun 25 08:24:23 2001
From: elguavas@users.sourceforge.net (Stephen)
Date: Mon, 25 Jun 2001 00:24:23 -0700
Subject: [Idle-dev] CVS: idle - Imported sources
Message-ID: <E15EQjP-0006Ao-00@usw-pr-cvs1.sourceforge.net>

Update of /cvsroot/idlefork/idle
In directory usw-pr-cvs1:/tmp/cvs-serv23617

Log Message:
import current python cvs idle as a vendor branch

Status:

Vendor Tag:	PYTHON_CVS_IDLE
Release Tags:	IMPORT_1_1
		
N idle/idle
U idle/AutoIndent.py
U idle/ParenMatch.py
U idle/PathBrowser.py
U idle/keydefs.py
U idle/config-unix.txt
N idle/RemoteInterp.py
U idle/FileList.py
U idle/IOBinding.py
U idle/TODO.txt
U idle/testcode.py
U idle/MultiScrolledLists.py
U idle/ClassBrowser.py
U idle/ScrolledList.py
U idle/MultiStatusBar.py
U idle/SearchEngine.py
U idle/CallTips.py
U idle/OldStackViewer.py
U idle/ScriptBinding.py
U idle/WidgetRedirector.py
U idle/Percolator.py
U idle/NEWS.txt
U idle/Delegator.py
U idle/WindowList.py
U idle/config-win.txt
U idle/config.txt
U idle/PyShell.py
U idle/GrepDialog.py
U idle/OutputWindow.py
U idle/idle.bat
U idle/idle.pyw
U idle/SearchDialogBase.py
U idle/EditorWindow.py
U idle/UndoDelegator.py
U idle/eventparse.py
U idle/idlever.py
U idle/AutoExpand.py
U idle/Debugger.py
U idle/ColorDelegator.py
U idle/IdleHistory.py
U idle/README.txt
U idle/FrameViewer.py
U idle/SearchBinding.py
U idle/StackViewer.py
U idle/extend.txt
U idle/CallTipWindow.py
U idle/idle.py
N idle/setup.py
U idle/ZoomHeight.py
U idle/ObjectBrowser.py
U idle/PyParse.py
U idle/ToolTip.py
U idle/ReplaceDialog.py
U idle/IdleConf.py
U idle/FormatParagraph.py
U idle/__init__.py
U idle/SearchDialog.py
U idle/ChangeLog
U idle/TreeWidget.py
U idle/help.txt
U idle/Bindings.py
U idle/Separator.py
U idle/Icons/plusnode.gif
U idle/Icons/openfolder.gif
U idle/Icons/python.gif
U idle/Icons/folder.gif
U idle/Icons/tk.gif
U idle/Icons/minusnode.gif

No conflicts created by this import


***** Bogus filespec: -
***** Bogus filespec: Imported
***** Bogus filespec: sources


From StephenM.Gava  Tue Jun 26 02:39:13 2001
From: StephenM.Gava (StephenM.Gava)
Date: Tue, 26 Jun 2001 11:39:13 +1000
Subject: [Idle-dev] idle-fork, cvs advice anyone?
Message-ID: <01062611391301.01412@oberon.casa-guava.org>

I'm in the process of trying to merge python/idle cvs into a branch of 
idle-fork cvs, but my previous cvs experience hasn't included merging from 
external sources and I want to make sure I'm going about this right.

>From reading as many cvs docs I as I could lay my hands on I've formed the 
impression that best way to acheive the desired result would be to follow 
these steps:

1. Tag the existing idlefork cvs pre branch point. (done)
2. Create idlefork cvs merging branch. (done, as "branch-python_idle_merging")
3. Export current python/idle cvs. (done) 
4. Import python/idle cvs to idlefork cvs as a vendor branch. (maybe done, 
after 3 tries,  with vendor tag "PYTHON_CVS_IDLE" and version tag 
"IMPORT_1_1") 
5. Merge python/cvs vendor branch into idlefork merge branch. (not done)
6. Merge idlefork merge branch back into idlefork trunk. (not done) 

For starters. Are the above steps a sensible process to achieve the desired 
result?  (This merge will need to be done from time to time, so I want to 
have a good way of doing it right form the start.)

If what I've done so far makes sense, then I so far got stalled at step 4.. 
The first couple of times I tried it, attempting to follow the steps from the 
cvs book and the Cerderdqvist, I ended up with idle/python imported into a 
new top level directory in the pythonfork cvs, which definitely isn't the 
desired effect (I probably shoudn't have rushed ahead and tried this at 
2am...) . The third (see above) time I think I was successful, but I'm not 
absolutely sure. 

In any case, since then I've made one quick try to check out a merged copy of 
the two relevant branches using "-j branch-python_idle_merging -j IMPORT_1_1" 
, but the results were not what I expected at all, so I went to bed. In the 
clear light of a new morning I thought I'd ask for advice on this before I 
try to go any further.

TIA for any help. I realise I should probably take this question to a cvs 
oriented forum, which I will do if noone here can help, but I just thought 
I'd try here first in case someone listenning has done this kind of thing a 
million times before.

Ciao, Stephen. 
-- 
Stephen M. Gava
<elguavas@users.sourceforge.net>
"More power to those who don't care for it." - anon


From kbk@shore.net  Tue Jun 26 04:55:35 2001
From: kbk@shore.net (Kurt B. Kaiser)
Date: 25 Jun 2001 23:55:35 -0400
Subject: [Idle-dev] idle-fork, cvs advice anyone?
In-Reply-To: <01062611391301.01412@oberon.casa-guava.org>
References: <01062611391301.01412@oberon.casa-guava.org>
Message-ID: <m38zifzyh4.fsf@float.ne.mediaone.com>

Stephen M. Gava <elguavas@users.sourceforge.net> writes:

> I'm in the process of trying to merge python/idle cvs into a branch of 
> idle-fork cvs, but my previous cvs experience hasn't included merging from 
> external sources and I want to make sure I'm going about this right.
> 
> >From reading as many cvs docs I as I could lay my hands on I've formed the 
> impression that best way to acheive the desired result would be to follow 
> these steps:
> 
> 1. Tag the existing idlefork cvs pre branch point. (done)
> 2. Create idlefork cvs merging branch. (done, as "branch-python_idle_merging")
> 3. Export current python/idle cvs. (done) 
> 4. Import python/idle cvs to idlefork cvs as a vendor branch. (maybe done, 
> after 3 tries,  with vendor tag "PYTHON_CVS_IDLE" and version tag 
> "IMPORT_1_1") 
> 5. Merge python/cvs vendor branch into idlefork merge branch. (not done)
> 6. Merge idlefork merge branch back into idlefork trunk. (not done) 
> 
> For starters. Are the above steps a sensible process to achieve the desired 
> result?  (This merge will need to be done from time to time, so I want to 
> have a good way of doing it right form the start.)

Hi Steven,

I've been looking at this also! As an initial comment, it appears that Scherer
imported the VPython IDLE into a vendor branch (1.1.1, the default) last
summer, and you have imported the Python IDLE into the same vendor branch. This
had the effect of removing Scherer's changes. For example, look at
AutoIndent.py, where Scherer had 1.1.1.1 and the Python IDLE version is
1.1.1.2.

The exception to this is the two cases (spawn.py, protocol.py) where Riley had
updated the VPython IDLE. There the HEAD has moved to MAIN, and your import is
not yet merged. (When a vendor branch is updated locally, HEAD moves off the
branch to MAIN.)

At this point I see "official-idle" at the top level, parallel with [VPython]
IDLE. I also see [Python] idle as a directory within the [VPython] idle
tree. Finally, I see [Python] IDLE as 1.1.1.2 revs in the [Vpython] idle tree.

As far as the overall structure goes, it seems we're trying to merge two
variants of IDLE. Are you assuming that the VPython version is the starting
point and the trunk of the development? As you say, we'll want to update
IDLE-fork from Python IDLE once in a while to add bug fixes, although there are
so few, it could be done manually.

I'm thinking about what might be the simplest structure (and how to get
there). Vendor branches are tricky!

Regards, KBK


From StephenM.Gava  Tue Jun 26 07:53:19 2001
From: StephenM.Gava (StephenM.Gava)
Date: Tue, 26 Jun 2001 16:53:19 +1000
Subject: [Idle-dev] idle-fork, cvs advice anyone?
In-Reply-To: <m38zifzyh4.fsf@float.ne.mediaone.com>
References: <01062611391301.01412@oberon.casa-guava.org> <m38zifzyh4.fsf@float.ne.mediaone.com>
Message-ID: <01062616531900.01596@oberon.casa-guava.org>

On Tue, 26 Jun 2001 01:55pm, Kurt B. Kaiser wrote:
> Stephen M. Gava <elguavas@users.sourceforge.net> writes:
> > I'm in the process of trying to merge python/idle cvs into a branch of
> > idle-fork cvs, but my previous cvs experience hasn't included merging
> > from external sources and I want to make sure I'm going about this right.
> >
> > >From reading as many cvs docs I as I could lay my hands on I've formed
> > > the impression that best way to acheive the desired result would be to 
> > >follow these steps:
> >
> > 1. Tag the existing idlefork cvs pre branch point. (done)
> > 2. Create idlefork cvs merging branch. (done, as
> > "branch-python_idle_merging") 3. Export current python/idle cvs. (done)
> > 4. Import python/idle cvs to idlefork cvs as a vendor branch. (maybe
> > done, after 3 tries,  with vendor tag "PYTHON_CVS_IDLE" and version tag
> > "IMPORT_1_1")
> > 5. Merge python/cvs vendor branch into idlefork merge branch. (not done)
> > 6. Merge idlefork merge branch back into idlefork trunk. (not done)
> >
> > For starters. Are the above steps a sensible process to achieve the
> > desired result?  (This merge will need to be done from time to time, so I
> > want to have a good way of doing it right form the start.)
>
> Hi Steven,
>
> I've been looking at this also! As an initial comment, it appears that
> Scherer imported the VPython IDLE into a vendor branch (1.1.1, the default)
> last summer, and you have imported the Python IDLE into the same vendor
> branch. 

Ahh, damn. I noticed the VPython branch when I first looked at idlefork, but 
then I subsequently forgot about it when I was trying to import an "official 
python idle" vendor a couple of days later. I guess, if the vendor branch is 
the right way to go for what I was hoping to achieve, I should have imported 
a vendor branch with an explicitly different branch number.

> This had the effect of removing Scherer's changes. For example,
> look at AutoIndent.py, where Scherer had 1.1.1.1 and the Python IDLE
> version is 1.1.1.2.
>
> The exception to this is the two cases (spawn.py, protocol.py) where Riley
> had updated the VPython IDLE. There the HEAD has moved to MAIN, and your
> import is not yet merged. (When a vendor branch is updated locally, HEAD
> moves off the branch to MAIN.)
>
> At this point I see "official-idle" at the top level, parallel with
> [VPython] IDLE. I also see [Python] idle as a directory within the
> [VPython] idle tree. Finally, I see [Python] IDLE as 1.1.1.2 revs in the
> [Vpython] idle tree. 

Yep. These were attempts 1, 2, and 3 by me to import python-idle as a vendor 
without remembering that the Vpython vendor branch was already there. 

> As far as the overall structure goes, it seems we're trying to merge two
> variants of IDLE. 

Yes. merging python-idle into the changes that have so far been made on the 
idlefork trunk. This will need to be done from time to time.  (although, I 
had intended to merge python-idle into a new branch of ithe idlefork trunk 
made just for this purpose, and then to merge that branch back to the trunk) 

> Are you assuming that the VPython version is the starting
> point and the trunk of the development? 

No I was assuming idlefork/idle was the trunk and that Vpython was added as a 
vendor branch (quite some time ago) so that desired Vpython changes could be 
mereged into idlefork/idle, and that this had already been done, so that 
idlefork/idle is where the action is and where the python-idle changes need 
to end up.  Then I stupidly forgot about the Vpython vendor branch when 
attempting step 4. on my list above.

> As you say, we'll want to update
> IDLE-fork from Python IDLE once in a while to add bug fixes, although there
> are so few, it could be done manually.

Yep.   Are there really so few changes? 

Huh, I'm just familiarising myself with the sources as a whole and I thought 
with the changes already made to idlefork (David Scherer told me that he 
already has a different variation of "separate process for execution" [which 
I was thinking may have originated in Vpython] in there and some other 
changes ), plus the changes in python-idlle since idlefork was forked off (it 
was forked at python-idle 0.5 I think, and python-idle in python 2.1 is 0.8, 
and Guido tells me he has made fresh changes since then), that there would be 
a significant amount of meging and conflict resolution to be done...   

That was one of my reasons for  wanting to import python-idle as a vendor 
branch rather than just using diff and patch and whatnot and doing it by hand 
locally and then just merging back to idlefork (or to a new branch at least 
at first).  

> I'm thinking about what might be the simplest structure (and how to get
> there). Vendor branches are tricky!

Hmm, so it seems for me at least...  8^{   My other reason for putting 
python-idle in as a vendor branch (unsucessfully, it seems), was because all 
the cvs admin stuff I read seemed to indicate that this was the way to handle 
external sources that will need to be repeatedly merged?

By all means if you can think of the simplest structure and how to get there 
to acheive this aim please do so, it would be a great help I think especially 
for future easy repeatability of the python-idle to idlefork merge. Maybe 
idlefork cvs does need to be put put in a new structure right from the start 
of this brave new era of idlefork? The idea hadn't occurred to me. What I've 
done so far with the failed vendor branches should be recoverable, I also 
tagged before I started, but if the last tarballs of idlefork are up to date 
we could even start a new repository from scratch if it was absolutely 
nesscesary I guess.   
>
> Regards, KBK

Anyway Kurt, thanks a lot for the help! 
Regards,
Stephen.
-- 
Stephen M. Gava
<elguavas@users.sourceforge.net>
"More power to those who don't care for it." - anon


From pobrien@orbtech.com  Tue Jun 26 15:09:20 2001
From: pobrien@orbtech.com (Patrick K. O'Brien)
Date: Tue, 26 Jun 2001 09:09:20 -0500
Subject: [Idle-dev] To fork, or not to fork?
Message-ID: <NBBBIOJPGKJEKIECEMCBMELDKBAA.pobrien@orbtech.com>

That is my question. I thought the immediate goal was to eliminate the need
for a fork by reconciling the changes that had been made to the two branches
in a way that supports the needs of both the official Python as well as
VPython. Then future development (revitalization) would occur against this
single new version of IDLE. Did I miss something?

All this talk of two branches and merging in the future and applying bug
fixes from one to the other has me confused.

---
Patrick K. O'Brien
Orbtech
"I am, therefore I think."




From kbk@shore.net  Tue Jun 26 15:44:48 2001
From: kbk@shore.net (Kurt B. Kaiser)
Date: 26 Jun 2001 10:44:48 -0400
Subject: [Idle-dev] idle-fork, cvs advice anyone?
In-Reply-To: <01062616531900.01596@oberon.casa-guava.org>
References: <01062611391301.01412@oberon.casa-guava.org>
 <m38zifzyh4.fsf@float.ne.mediaone.com>
 <01062616531900.01596@oberon.casa-guava.org>
Message-ID: <m3lmmfti5b.fsf@float.ne.mediaone.com>

Stephen M. Gava <elguavas@users.sourceforge.net> writes:
 
> By all means if you can think of the simplest structure and how to get there 
> to acheive this aim please do so, it would be a great help I think especially 
Stephen,

After sleeping on it, here's my thinking:  

I make the assumption we are starting with the VPython version of IDLE, merging
recent changes from Python IDLE, and continuing development through changes at
IDLE-fork plus occasional patches from Python IDLE.

CVS appears to "use up" the default 1.1.1 vendor branch during any initial
import; the canonical vendortag is the username and the releasetag is
"start". In the case of VPython IDLE, it appears the vendortag was "avendor"
and the releasetag was "arelease".

If VPython IDLE was still being developed then we would want to merge its
updates also, but it doesn't seem that that is a consideration. (If it were,
the new release could be imported again on the "avendor" branch.)

For simplicity, assume that the changes you made are backed out. Then one
approach is to have the IDLE-fork trunk and two vendor branches, VPython IDLE
and Python IDLE. Development would proceed along the trunk, with occasional
merges from the vendor branches. No other branches seem necessary at this time.

In the case of the VPython branch, there is probably going to be only the one
merge of what we have, but I suspect it will have to be done explicitly to get
the file HEADs off the branch and onto the trunk so they can be merged with the
other (Python) vendor branch: update -A and then update -j arelease.

As far as the Python IDLE branch goes, what we are interested in is the changes
since VPython IDLE forked. It looks like the idle05 tag in the Python CVS was
established June 11, 1999. Maybe Dave Scherer remembers the DATE he downloaded,
it might be later than that.  What I would suggest is to export a version of
Python IDLE as of midnight GMT of DATE - 1. Import this into branch 1.1.3 with
python-cvs vendortag and a releasetag something like python-cvs-fork.

Next, export the current version of Python IDLE and import it into the same
1.1.3 python-cvs vendor branch with releasetag something like
update-20010626. The diffs can be checked out into a local directory via
checkout -j python-cvs-fork -j update-20010626 and reviewed individually. Some
of them may conflict conceptually with IDLE-fork.

The merge of acceptable diffs can be accomplished by update -A and
     update -j python-cvs-fork -j update-20010626 filename

I assume the gurus on the list will double check all this and identify any
misconceptions or improvements!

Regards, KBK


From guido@digicool.com  Tue Jun 26 16:27:11 2001
From: guido@digicool.com (Guido van Rossum)
Date: Tue, 26 Jun 2001 11:27:11 -0400
Subject: [Idle-dev] To fork, or not to fork?
In-Reply-To: Your message of "Tue, 26 Jun 2001 09:09:20 CDT."
 <NBBBIOJPGKJEKIECEMCBMELDKBAA.pobrien@orbtech.com>
References: <NBBBIOJPGKJEKIECEMCBMELDKBAA.pobrien@orbtech.com>
Message-ID: <200106261527.f5QFRBb11218@odiug.digicool.com>

> That is my question. I thought the immediate goal was to eliminate the need
> for a fork by reconciling the changes that had been made to the two branches
> in a way that supports the needs of both the official Python as well as
> VPython. Then future development (revitalization) would occur against this
> single new version of IDLE. Did I miss something?
> 
> All this talk of two branches and merging in the future and applying bug
> fixes from one to the other has me confused.

The point of the fork is to enable a smaller, more focused group of
developers to work on IDLE without having to earn commit privileges to
the Python tree.  Divide and conquer, so to speak.  If all goes well,
eventually this will be merged back into the main Python CVS tree.  In
the mean time, I promise not to make any changes to IDLE in the Python
CVS tree (unless I'm absolutely forced by circumstances, like the
addition of the "yield" keyword).

--Guido van Rossum (home page: http://www.python.org/~guido/)


From pobrien@orbtech.com  Tue Jun 26 16:41:20 2001
From: pobrien@orbtech.com (Patrick K. O'Brien)
Date: Tue, 26 Jun 2001 10:41:20 -0500
Subject: [Idle-dev] To fork, or not to fork?
In-Reply-To: <200106261527.f5QFRBb11218@odiug.digicool.com>
Message-ID: <NBBBIOJPGKJEKIECEMCBAELJKBAA.pobrien@orbtech.com>

Okay, now I understand. Thanks.

---
Patrick K. O'Brien
Orbtech
"I am, therefore I think."

-----Original Message-----
From: guido@odiug.digicool.com [mailto:guido@odiug.digicool.com]On Behalf Of
Guido van Rossum
Sent: Tuesday, June 26, 2001 10:27 AM
To: pobrien@orbtech.com
Cc: IDLE Developers List
Subject: Re: [Idle-dev] To fork, or not to fork?

> That is my question. I thought the immediate goal was to eliminate the
need
> for a fork by reconciling the changes that had been made to the two
branches
> in a way that supports the needs of both the official Python as well as
> VPython. Then future development (revitalization) would occur against this
> single new version of IDLE. Did I miss something?
>
> All this talk of two branches and merging in the future and applying bug
> fixes from one to the other has me confused.

The point of the fork is to enable a smaller, more focused group of
developers to work on IDLE without having to earn commit privileges to
the Python tree.  Divide and conquer, so to speak.  If all goes well,
eventually this will be merged back into the main Python CVS tree.  In
the mean time, I promise not to make any changes to IDLE in the Python
CVS tree (unless I'm absolutely forced by circumstances, like the
addition of the "yield" keyword).

--Guido van Rossum (home page: http://www.python.org/~guido/)



From elguavas@users.sourceforge.net  Wed Jun 27 01:24:37 2001
From: elguavas@users.sourceforge.net (Stephen)
Date: Tue, 26 Jun 2001 17:24:37 -0700
Subject: [Idle-dev] CVS: idle IDLEFORK.html,1.5,1.6
Message-ID: <E15F38H-0006T1-00@usw-pr-cvs1.sourceforge.net>

Update of /cvsroot/idlefork/idle
In directory usw-pr-cvs1:/tmp/cvs-serv24850

Modified Files:
	IDLEFORK.html 
Log Message:
updated contact details

Index: IDLEFORK.html
===================================================================
RCS file: /cvsroot/idlefork/idle/IDLEFORK.html,v
retrieving revision 1.5
retrieving revision 1.6
diff -C2 -r1.5 -r1.6
*** IDLEFORK.html	2001/06/24 05:10:41	1.5
--- IDLEFORK.html	2001/06/27 00:24:34	1.6
***************
*** 33,42 ****
  regularly, you can become a developer by mailing the project
  coordinator, <a href="mailto:elguavas@users.sourceforge.net">Stephen M. Gava
!  [<tt>elguavas@users.sourceforge.net</tt>]</a>.
  
  <h4><a name="discussion" id="discussion"></a>Discussion</h4>
  Discussion of development for IDLE is carried out on the <a
  href="mailto:idle-dev@python.org">idle-dev mailing list
! [<tt>idle-dev@python.org</tt>]</a> at the <a
  href="http://www.python.org">Python Language Website</a>. Subscription
  information can be found at:
--- 33,42 ----
  regularly, you can become a developer by mailing the project
  coordinator, <a href="mailto:elguavas@users.sourceforge.net">Stephen M. Gava
!  [<tt>elguavas at users.sourceforge.net</tt>]</a>.
  
  <h4><a name="discussion" id="discussion"></a>Discussion</h4>
  Discussion of development for IDLE is carried out on the <a
  href="mailto:idle-dev@python.org">idle-dev mailing list
! [<tt>idle-dev at python.org</tt>]</a> at the <a
  href="http://www.python.org">Python Language Website</a>. Subscription
  information can be found at:



From StephenM.Gava  Wed Jun 27 02:08:34 2001
From: StephenM.Gava (StephenM.Gava)
Date: Wed, 27 Jun 2001 11:08:34 +1000
Subject: [Idle-dev] idle-fork, cvs advice anyone?
In-Reply-To: <m3lmmfti5b.fsf@float.ne.mediaone.com>
References: <01062611391301.01412@oberon.casa-guava.org> <01062616531900.01596@oberon.casa-guava.org> <m3lmmfti5b.fsf@float.ne.mediaone.com>
Message-ID: <01062711083400.09765@oberon.casa-guava.org>

On Wed, 27 Jun 2001 12:44am, Kurt B. Kaiser wrote:
> Stephen M. Gava <elguavas@users.sourceforge.net> writes:
> > By all means if you can think of the simplest structure and how to get
> > there to acheive this aim please do so, it would be a great help I think
> > especially
>
> Stephen,
>
> After sleeping on it, here's my thinking:
>
> I make the assumption we are starting with the VPython version of IDLE,
> merging recent changes from Python IDLE, and continuing development through
> changes at IDLE-fork plus occasional patches from Python IDLE
>
> CVS appears to "use up" the default 1.1.1 vendor branch during any initial
> import; the canonical vendortag is the username and the releasetag is
> "start". In the case of VPython IDLE, it appears the vendortag was
> "avendor" and the releasetag was "arelease".
>
> If VPython IDLE was still being developed then we would want to merge its
> updates also, but it doesn't seem that that is a consideration. (If it
> were, the new release could be imported again on the "avendor" branch.)
>
> For simplicity, assume that the changes you made are backed out. Then one
> approach is to have the IDLE-fork trunk and two vendor branches, VPython
> IDLE and Python IDLE. Development would proceed along the trunk, with
> occasional merges from the vendor branches. No other branches seem
> necessary at this time.

The Vpython vendor branch is not required to be ongoing. Vpython should have 
been imported and merged once with python-idle at the beginning to give the 
ongoing idlefork trunk. From then on the only external merging required into 
idlefork should be occasional minor ones from python-idle. 

The only other major initial external change to idlefork will probably be 
Guido's own "external process execution" work which will likely come to me as 
a patch and may require the removal of, or merging with, David Scherer's 
implementation of this feature.   

> In the case of the VPython branch, there is probably going to be only the
> one merge of what we have, but I suspect it will have to be done explicitly
> to get the file HEADs off the branch and onto the trunk so they can be
> merged with the other (Python) vendor branch: update -A and then update -j
> arelease.
>
> As far as the Python IDLE branch goes, what we are interested in is the
> changes since VPython IDLE forked. It looks like the idle05 tag in the
> Python CVS was established June 11, 1999. Maybe Dave Scherer remembers the
> DATE he downloaded, it might be later than that.  What I would suggest is
> to export a version of Python IDLE as of midnight GMT of DATE - 1. Import
> this into branch 1.1.3 with python-cvs vendortag and a releasetag something
> like python-cvs-fork.
>
> Next, export the current version of Python IDLE and import it into the same
> 1.1.3 python-cvs vendor branch with releasetag something like
> update-20010626. The diffs can be checked out into a local directory via
> checkout -j python-cvs-fork -j update-20010626 and reviewed individually.
> Some of them may conflict conceptually with IDLE-fork.
>
> The merge of acceptable diffs can be accomplished by update -A and
>      update -j python-cvs-fork -j update-20010626 filename
>
> I assume the gurus on the list will double check all this and identify any
> misconceptions or improvements!

I think this ends up pretty much equalling in results the process I set out 
conceptually to follow, but as I mentionned I got stuffed up by not importing 
python IDLE into 1.1.3 (as you have it above) so it took over the default 
vendor branch where Vpython was. 

Apart from any possible corrections by any helpful listening gurus (Anyone??) 
do you feel confident to follow the steps you've outlined (starting with 
reverting my earlier attempt), and to complete the initial setup, up to the 
stage where the diffs on the final merge are ready to be reviewed?
-- 
Stephen M. Gava
<elguavas@users.sourceforge.net>
"More power to those who don't care for it." - anon


From mail@peterbe.com  Fri Jun 29 15:30:26 2001
From: mail@peterbe.com (Peter Bengtsson)
Date: Fri, 29 Jun 2001 16:30:26 +0200
Subject: [Idle-dev] rightclick
Message-ID: <023301c100a8$b70b95a0$1c64a8c0@PBN>

1) In windows, how do I (if possible) right-click a py file and open it in
IDLE?

2) In windows, how do I (if possible with some hacking) right-click a py
file and open it in IDLE?

3) Where's the mailinglist archive for this mailing list? I never did any
research before question 1 and 2.


Cheers, Peter



From pobrien@orbtech.com  Fri Jun 29 16:09:25 2001
From: pobrien@orbtech.com (Patrick K. O'Brien)
Date: Fri, 29 Jun 2001 10:09:25 -0500
Subject: [Idle-dev] rightclick
In-Reply-To: <023301c100a8$b70b95a0$1c64a8c0@PBN>
Message-ID: <NBBBIOJPGKJEKIECEMCBOEDBKCAA.pobrien@orbtech.com>

In Windows Explorer, Tools | Folder Options | File Types scroll down the
list and select Python File. Hit the Edit button. In the Edit File Type
dialog hit the New button. In the Action field type in "Edit in IDLE" and in
the Application used to perform action field type in
"C:\Python21\pythonw.exe C:\PYTHON21\Tools\idle\idle.pyw -s -e". The -s
switch is optional and will load your PYTHONSTARTUP script. The -e says to
edit the file. The location of pythonw.exe and idle.pyw depends on your
installation.

Having done this, you can now right click on a .py file and you will have an
option to "Edit in IDLE". The only drawback to this technique is that if
IDLE is already running, a second shell window will open as well as the file
you want to edit.

Hope that helps.

---
Patrick K. O'Brien
Orbtech
"I am, therefore I think."

-----Original Message-----
From: idle-dev-admin@python.org [mailto:idle-dev-admin@python.org]On Behalf
Of Peter Bengtsson
Sent: Friday, June 29, 2001 9:30 AM
To: idle-dev@python.org
Subject: [Idle-dev] rightclick

1) In windows, how do I (if possible) right-click a py file and open it in
IDLE?

2) In windows, how do I (if possible with some hacking) right-click a py
file and open it in IDLE?

3) Where's the mailinglist archive for this mailing list? I never did any
research before question 1 and 2.


Cheers, Peter


_______________________________________________
IDLE-dev mailing list
IDLE-dev@python.org
http://mail.python.org/mailman/listinfo/idle-dev



From kbk@users.sourceforge.net  Fri Jun 29 21:04:28 2001
From: kbk@users.sourceforge.net (Kurt B. Kaiser)
Date: Fri, 29 Jun 2001 13:04:28 -0700
Subject: [Idle-dev] CVS: official-idle/Icons folder.gif,1.1.1.1,NONE minusnode.gif,1.1.1.1,NONE openfolder.gif,1.1.1.1,NONE plusnode.gif,1.1.1.1,NONE python.gif,1.1.1.1,NONE tk.gif,1.1.1.1,NONE
Message-ID: <E15G4VA-0000Iy-00@usw-pr-cvs1.sourceforge.net>

Update of /cvsroot/idlefork/official-idle/Icons
In directory usw-pr-cvs1:/tmp/cvs-serv1163

Removed Files:
	folder.gif minusnode.gif openfolder.gif plusnode.gif 
	python.gif tk.gif 
Log Message:
Remove all files from official-idle/Icon directory

--- folder.gif DELETED ---

--- minusnode.gif DELETED ---

--- openfolder.gif DELETED ---

--- plusnode.gif DELETED ---

--- python.gif DELETED ---

--- tk.gif DELETED ---



From kbk@users.sourceforge.net  Fri Jun 29 21:12:02 2001
From: kbk@users.sourceforge.net (Kurt B. Kaiser)
Date: Fri, 29 Jun 2001 13:12:02 -0700
Subject: [Idle-dev] CVS: official-idle AutoExpand.py,1.1.1.1,NONE AutoIndent.py,1.1.1.1,NONE Bindings.py,1.1.1.1,NONE CallTipWindow.py,1.1.1.1,NONE CallTips.py,1.1.1.1,NONE ChangeLog,1.1.1.1,NONE ClassBrowser.py,1.1.1.1,NONE ColorDelegator.py,1.1.1.1,NONE Debugger.py,1.1.1.1,NONE Delegator.py,1.1.1.1,NONE EditorWindow.py,1.1.1.1,NONE FileList.py,1.1.1.1,NONE FormatParagraph.py,1.1.1.1,NONE FrameViewer.py,1.1.1.1,NONE GrepDialog.py,1.1.1.1,NONE IOBinding.py,1.1.1.1,NONE IdleConf.py,1.1.1.1,NONE IdleHistory.py,1.1.1.1,NONE MultiScrolledLists.py,1.1.1.1,NONE MultiStatusBar.py,1.1.1.1,NONE NEWS.txt,1.1.1.1,NONE ObjectBrowser.py,1.1.1.1,NONE OldStackViewer.py,1.1.1.1,NONE OutputWindow.py,1.1.1.1,NONE ParenMatch.py,1.1.1.1,NONE PathBrowser.py,1.1.1.1,NONE Percolator.py,1.1.1.1,NONE PyParse.py,1.1.1.1,NONE PyShell.py,1.1.1.1,NONE README.txt,1.1.1.1,NONE RemoteInterp.py,1.1.1.1,NONE ReplaceDialog.py,1.1.1.1,NONE ScriptBinding.py,1.1.1.1,NONE ScrolledList.py,1.1.1.1,NONE SearchBinding.py,1.1.1.1,NONE SearchDialog.py,1.1.1.1,NONE SearchDialogBase.py,1.1.1.1,NONE SearchEngine.py,1.1.1.1,NONE Separator.py,1.1.1.1,NONE StackViewer.py,1.1.1.1,NONE TODO.txt,1.1.1.1,NONE ToolTip.py,1.1.1.1,NONE TreeWidget.py,1.1.1.1,NONE UndoDelegator.py,1.1.1.1,NONE WidgetRedirector.py,1.1.1.1,NONE WindowList.py,1.1.1.1,NONE ZoomHeight.py,1.1.1.1,NONE __init__.py,1.1.1.1,NONE config-unix.txt,1.1.1.1,NONE config-win.txt,1.1.1.1,NONE config.txt,1.1.1.1,NONE eventparse.py,1.1.1.1,NONE extend.txt,1.1.1.1,NONE help.txt,1.1.1.1,NONE idle,1.1.1.1,NONE idle.bat,1.1.1.1,NONE idle.py,1.1.1.1,NONE idle.pyw,1.1.1.1,NONE idlever.py,1.1.1.1,NONE keydefs.py,1.1.1.1,NONE setup.py,1.1.1.1,NONE testcode.py,1.1.1.1,NONE
Message-ID: <E15G4cU-0000m7-00@usw-pr-cvs1.sourceforge.net>

Update of /cvsroot/idlefork/official-idle
In directory usw-pr-cvs1:/tmp/cvs-serv2938

Removed Files:
	AutoExpand.py AutoIndent.py Bindings.py CallTipWindow.py 
	CallTips.py ChangeLog ClassBrowser.py ColorDelegator.py 
	Debugger.py Delegator.py EditorWindow.py FileList.py 
	FormatParagraph.py FrameViewer.py GrepDialog.py IOBinding.py 
	IdleConf.py IdleHistory.py MultiScrolledLists.py 
	MultiStatusBar.py NEWS.txt ObjectBrowser.py OldStackViewer.py 
	OutputWindow.py ParenMatch.py PathBrowser.py Percolator.py 
	PyParse.py PyShell.py README.txt RemoteInterp.py 
	ReplaceDialog.py ScriptBinding.py ScrolledList.py 
	SearchBinding.py SearchDialog.py SearchDialogBase.py 
	SearchEngine.py Separator.py StackViewer.py TODO.txt 
	ToolTip.py TreeWidget.py UndoDelegator.py WidgetRedirector.py 
	WindowList.py ZoomHeight.py __init__.py config-unix.txt 
	config-win.txt config.txt eventparse.py extend.txt help.txt 
	idle idle.bat idle.py idle.pyw idlever.py keydefs.py setup.py 
	testcode.py 
Log Message:
Remove all files from official-idle directory.

--- AutoExpand.py DELETED ---

--- AutoIndent.py DELETED ---

--- Bindings.py DELETED ---

--- CallTipWindow.py DELETED ---

--- CallTips.py DELETED ---

--- ChangeLog DELETED ---

--- ClassBrowser.py DELETED ---

--- ColorDelegator.py DELETED ---

--- Debugger.py DELETED ---

--- Delegator.py DELETED ---

--- EditorWindow.py DELETED ---

--- FileList.py DELETED ---

--- FormatParagraph.py DELETED ---

--- FrameViewer.py DELETED ---

--- GrepDialog.py DELETED ---

--- IOBinding.py DELETED ---

--- IdleConf.py DELETED ---

--- IdleHistory.py DELETED ---

--- MultiScrolledLists.py DELETED ---

--- MultiStatusBar.py DELETED ---

--- NEWS.txt DELETED ---

--- ObjectBrowser.py DELETED ---

--- OldStackViewer.py DELETED ---

--- OutputWindow.py DELETED ---

--- ParenMatch.py DELETED ---

--- PathBrowser.py DELETED ---

--- Percolator.py DELETED ---

--- PyParse.py DELETED ---

--- PyShell.py DELETED ---

--- README.txt DELETED ---

--- RemoteInterp.py DELETED ---

--- ReplaceDialog.py DELETED ---

--- ScriptBinding.py DELETED ---

--- ScrolledList.py DELETED ---

--- SearchBinding.py DELETED ---

--- SearchDialog.py DELETED ---

--- SearchDialogBase.py DELETED ---

--- SearchEngine.py DELETED ---

--- Separator.py DELETED ---

--- StackViewer.py DELETED ---

--- TODO.txt DELETED ---

--- ToolTip.py DELETED ---

--- TreeWidget.py DELETED ---

--- UndoDelegator.py DELETED ---

--- WidgetRedirector.py DELETED ---

--- WindowList.py DELETED ---

--- ZoomHeight.py DELETED ---

--- __init__.py DELETED ---

--- config-unix.txt DELETED ---

--- config-win.txt DELETED ---

--- config.txt DELETED ---

--- eventparse.py DELETED ---

--- extend.txt DELETED ---

--- help.txt DELETED ---

--- idle DELETED ---

--- idle.bat DELETED ---

--- idle.py DELETED ---

--- idle.pyw DELETED ---

--- idlever.py DELETED ---

--- keydefs.py DELETED ---

--- setup.py DELETED ---

--- testcode.py DELETED ---