headers
Guilherme Polo | 4 Aug 2009 15:25
Picon
Gravatar

Merging VIDLE differences into idlelib

Hi there,

I have verified the VIDLE fork last week expecting to find many
differences between it and IDLE. Most files differ but it turned out
that most of these differences are equivalent (many of the changes
were merged already), except for two of them. One of these changes is
related to py2app, so I can't verify it. The second is about using the
subprocess module to spawn the subprocess, so it is easier to
terminate it properly under Windows (the original code was a bit
different since it was done before Python 2.6). I'm not a heavy
Windows so I can't tell how much this helps, my guess is that it would
help with http://bugs.python.org/issue2708.

Do anyone believe these changes could help IDLE ?

Index: Lib/idlelib/PyShell.py
===================================================================
--- Lib/idlelib/PyShell.py	(revision 74191)
+++ Lib/idlelib/PyShell.py	(working copy)
 <at>  <at>  -11,6 +11,7  <at>  <at> 
 import threading
 import traceback
 import types
+import subprocess
 import macosxSupport

 import linecache
 <at>  <at>  -40,11 +41,6  <at>  <at> 
 HOST = '127.0.0.1' # python execution server on localhost loopback
 PORT = 0  # someday pass in host, port for remote debug capability
(Continue reading)

Permalink | Reply | 3 comments |
headers
Ned Deily | 4 Aug 2009 19:55
Picon
Favicon
Gravatar

Re: Merging VIDLE differences into idlelib

In article 
<ac2200130908040625qac2c52bg8946ae26e40e15ec <at> mail.gmail.com>,
 Guilherme Polo <ggpolo <at> gmail.com> wrote:
> I have verified the VIDLE fork last week expecting to find many
> differences between it and IDLE. Most files differ but it turned out
> that most of these differences are equivalent (many of the changes
> were merged already), except for two of them. One of these changes is
> related to py2app, so I can't verify it.

[...]

> Index: Lib/idlelib/macosxSupport.py
> ===================================================================
> --- Lib/idlelib/macosxSupport.py	(revision 74191)
> +++ Lib/idlelib/macosxSupport.py	(working copy)
>  <at>  <at>  -9,7 +9,7  <at>  <at> 
>      """
>      Returns True if Python is running from within an app on OSX.
>      If so, assume that Python was built with Aqua Tcl/Tk rather than
> -    X11 Tck/Tk.
> +    X11 Tcl/Tk.
>      """
>      return (sys.platform == 'darwin' and '.app' in sys.executable)
> 
>  <at>  <at>  -121,6 +121,13  <at>  <at> 
>                          menu.add_command(label=label, underline=underline,
>                          command=command, accelerator=accelerator)
> 
> +def preprocessArguments():
> +    # Deal with spurious argument passed by Finder, so "argv emulation" is
(Continue reading)

Permalink | Reply | 2 comments |
headers
Guilherme Polo | 4 Aug 2009 20:16
Picon
Gravatar

Re: Merging VIDLE differences into idlelib

2009/8/4 Ned Deily <nad <at> acm.org>:
> In article
> <ac2200130908040625qac2c52bg8946ae26e40e15ec <at> mail.gmail.com>,
>  Guilherme Polo <ggpolo <at> gmail.com> wrote:
>> I have verified the VIDLE fork last week expecting to find many
>> differences between it and IDLE. Most files differ but it turned out
>> that most of these differences are equivalent (many of the changes
>> were merged already), except for two of them. One of these changes is
>> related to py2app, so I can't verify it.
>
> [...]
>
>> Index: Lib/idlelib/macosxSupport.py
>> ===================================================================
>> --- Lib/idlelib/macosxSupport.py      (revision 74191)
>> +++ Lib/idlelib/macosxSupport.py      (working copy)
>>  <at>  <at>  -9,7 +9,7  <at>  <at> 
>>      """
>>      Returns True if Python is running from within an app on OSX.
>>      If so, assume that Python was built with Aqua Tcl/Tk rather than
>> -    X11 Tck/Tk.
>> +    X11 Tcl/Tk.
>>      """
>>      return (sys.platform == 'darwin' and '.app' in sys.executable)
>>
>>  <at>  <at>  -121,6 +121,13  <at>  <at> 
>>                          menu.add_command(label=label, underline=underline,
>>                          command=command, accelerator=accelerator)
>>
>> +def preprocessArguments():
(Continue reading)

Permalink | Reply | 1 comment |
headers
Ned Deily | 4 Aug 2009 20:34
Picon
Favicon
Gravatar

Re: Merging VIDLE differences into idlelib

In article 
<ac2200130908041116l2d614180me8086df4428e3a44 <at> mail.gmail.com>,
 Guilherme Polo <ggpolo <at> gmail.com> wrote:
> I'm aware of py2app not being used by IDLE (or anything else in std
> lib), but what prevents someone from running py2app on idlelib and
> getting an similar IDLE.app ? I'm really not into Mac, but isn't this
> IDLE.app just an bundle that could be similarly built with py2app ?

There's nothing preventing someone from trying to create their own 
variant of an IDLE.app but it's probably a bit tricky to get everything 
right even with py2app and, since the standard python.org OS X 
installers already provide two ways to launch IDLE (as an .app and from 
the command line), I don't see providing hooks in idlelib for yet 
another way as a significant use case.

--

-- 
 Ned Deily,
 nad <at> acm.org
Permalink | Reply | 0 comments |
headers
Guilherme Polo | 17 Aug 2009 15:01
Picon
Gravatar

Some implemented ideas that may help IDLE, request for feedback

Hello,

These days I have been talking a lot with Bruce Sherwood, who is a
great enthusiast about IDLE and has watched large numbers of novice
users of IDLE, and several ideas have been proposed and are now
implemented on a branch living on svn.python.org. Some of the changes
were proposed by David Scherer, who created the modern idlefork in the
year 2000. I would like to see most or all of the changes merged into
Python and here I am hoping I can get some feedback.

Below are the ideas that have been implemented recently in the context
of part of a Google Summer of Code project:

* Allow running code without explicitly saving it before. This has
been added in such way to allow the default settings to preserve the
current behaviour. In this case when an exception occurs, the
temporary file name is substituted by "Untitled" on the traceback. At
some point, this option was available in the 2000 idlefork and has
been sorely missed by those users who prefer to write little test
routines in an edit window rather than in the shell window; without
this capability it is distracting to have to choose a place to save a
test file. Upon exit from IDLE the user is asked whether to save the
file permanently.

* Bring IDLE's shell forward on first thing printed to sys.stderr,
this can only happen again after a shell restart. I consider this of
great importance when writing programs that may open other windows,
like a Tkinter program, or a Visual one, since the user might expect
something to happen on that window but nothing happens because of an
error that occurred without him noticing. As reported by Bruce, the
(Continue reading)

Permalink | Reply | 17 comments |
headers
Michael Foord | 17 Aug 2009 15:11
Picon
Favicon
Gravatar

Re: Some implemented ideas that may help IDLE, request for feedback

Guilherme Polo wrote:
> Hello,
>
> These days I have been talking a lot with Bruce Sherwood, who is a
> great enthusiast about IDLE and has watched large numbers of novice
> users of IDLE, and several ideas have been proposed and are now
> implemented on a branch living on svn.python.org. Some of the changes
> were proposed by David Scherer, who created the modern idlefork in the
> year 2000. I would like to see most or all of the changes merged into
> Python and here I am hoping I can get some feedback.
>
> Below are the ideas that have been implemented recently in the context
> of part of a Google Summer of Code project:
>
> * Allow running code without explicitly saving it before. This has
> been added in such way to allow the default settings to preserve the
> current behaviour. In this case when an exception occurs, the
> temporary file name is substituted by "Untitled" on the traceback. At
> some point, this option was available in the 2000 idlefork and has
> been sorely missed by those users who prefer to write little test
> routines in an edit window rather than in the shell window; without
> this capability it is distracting to have to choose a place to save a
> test file. Upon exit from IDLE the user is asked whether to save the
> file permanently.
>   

+1 (or more if I could)

> * Bring IDLE's shell forward on first thing printed to sys.stderr,
> this can only happen again after a shell restart. I consider this of
(Continue reading)

Permalink | Reply | 16 comments |
headers
Guilherme Polo | 17 Aug 2009 15:27
Picon
Gravatar

Re: Some implemented ideas that may help IDLE, request for feedback

2009/8/17 Michael Foord <fuzzyman <at> voidspace.org.uk>:
> Guilherme Polo wrote:
>> * Bring IDLE's shell forward on first thing printed to sys.stderr,
>> this can only happen again after a shell restart. I consider this of
>> great importance when writing programs that may open other windows,
>> like a Tkinter program, or a Visual one, since the user might expect
>> something to happen on that window but nothing happens because of an
>> error that occurred without him noticing. As reported by Bruce, the
>> lack of this feature has been a big problem in courses where novices
>> write such programs and don't understand why an animation has stopped,
>> because the error message is behind other windows.
>>
>>
>
> -0  (doesn't this mean having to *constantly* move the window out of the way
> when your logging code causes it to jump in front of your GUI)

Depending on the level of the logging, yes but only the first time. If
you do, for instance, logging.error('buh') followed by many others,
just the first call would bring the window forward.
I have considered making this optional too, since it is very likely
that some people won't like this supposed distraction even if it is
telling about some possible error.

>
>> * Terminate the server process under Windows too. On python trunk this
>> is done only for platforms that support os.kill.
>>
>
> +1
(Continue reading)

Permalink | Reply | 2 comments |
headers
Michael Foord | 17 Aug 2009 15:38
Picon
Favicon
Gravatar

Re: Some implemented ideas that may help IDLE, request for feedback

Guilherme Polo wrote:
> [snip...]
>> Unfortunately IDLE on the Mac is not very good looking
>> (a Tk problem rather than an IDLE problem I think) which means I have less
>> motivation to use it since I left Windows as my main dev environment.
>>
>>     
>
> I understand. Doesn't ttk widgets improve anything there ? I don't
> have a mac and I rarely see a mac, so I really don't know how it looks
> like there. IDLE isn't using ttk widgets, but last year I did
> something that would use them when available so it could be worth the
> effort to adapt it to the current IDLE code.
>
>   

I think that in principle ttk would help, but doesn't Python ship its 
*own* version of Tk *or* use the system Tk - neither of which have ttk 
available.

I'm nothing like a Tk expert, but if there are instructions on how to 
try then I can give it a go. If you have the code then I can do some 
research (as and when I have time).

All the best,

Michael
>> Michael
>>
>>
(Continue reading)

Permalink | Reply | 1 comment |
headers
Guilherme Polo | 17 Aug 2009 15:44
Picon
Gravatar

Re: Some implemented ideas that may help IDLE, request for feedback

2009/8/17 Michael Foord <fuzzyman <at> voidspace.org.uk>:
> Guilherme Polo wrote:
>>
>> [snip...]
>>>
>>> Unfortunately IDLE on the Mac is not very good looking
>>> (a Tk problem rather than an IDLE problem I think) which means I have
>>> less
>>> motivation to use it since I left Windows as my main dev environment.
>>>
>>>
>>
>> I understand. Doesn't ttk widgets improve anything there ? I don't
>> have a mac and I rarely see a mac, so I really don't know how it looks
>> like there. IDLE isn't using ttk widgets, but last year I did
>> something that would use them when available so it could be worth the
>> effort to adapt it to the current IDLE code.
>>
>>
>
> I think that in principle ttk would help, but doesn't Python ship its *own*
> version of Tk *or* use the system Tk - neither of which have ttk available.
>

If the system Tk version is 8.5 or newer then ttk is included,
otherwise you need to install tile.

> I'm nothing like a Tk expert, but if there are instructions on how to try
> then I can give it a go. If you have the code then I can do some research
> (as and when I have time).
(Continue reading)

Permalink | Reply | 0 comments |
headers
Tal Einat | 17 Aug 2009 15:55
Picon
Gravatar

Re: Some implemented ideas that may help IDLE, request for feedback

Michael Foord wrote:
> Guilherme Polo wrote:
>>
>> * Allow running code without explicitly saving it before. This has
>> been added in such way to allow the default settings to preserve the
>> current behaviour. In this case when an exception occurs, the
>> temporary file name is substituted by "Untitled" on the traceback. At
>> some point, this option was available in the 2000 idlefork and has
>> been sorely missed by those users who prefer to write little test
>> routines in an edit window rather than in the shell window; without
>> this capability it is distracting to have to choose a place to save a
>> test file. Upon exit from IDLE the user is asked whether to save the
>> file permanently.
>
> +1 (or more if I could)

+1 as well

>> * Bring IDLE's shell forward on first thing printed to sys.stderr,
>> this can only happen again after a shell restart. I consider this of
>> great importance when writing programs that may open other windows,
>> like a Tkinter program, or a Visual one, since the user might expect
>> something to happen on that window but nothing happens because of an
>> error that occurred without him noticing. As reported by Bruce, the
>> lack of this feature has been a big problem in courses where novices
>> write such programs and don't understand why an animation has stopped,
>> because the error message is behind other windows.
>
> -0  (doesn't this mean having to *constantly* move the window out of the way
> when your logging code causes it to jump in front of your GUI)
(Continue reading)

Permalink | Reply | 12 comments |

Gmane