An idea and a bug

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

Re: An idea and a bug

On 8/7/07, Jameson Chema Quinn <jquinn <at> cs.oberlin.edu> wrote:
> I'm hacking at my own version of IDLE to try to implement language support
> in Python. I found a bug.
>
> 1. The bug.
> I'm using IDLE to work on a copy of IDLE in my home directory. I copy the
> idlelib directory to ~/jqidlelib , add "jq" to lines 2 and 22 of idle.py,
> open it in IDLE, and start hacking on the other files. If a hacked version
> of some other module is not open in IDLE and I press F5 to run idle.py, I
> get the desired behaviour (the modules are loaded from my hacked copies) but
> the error display is wacky. Errors refer to the line numbers of my hacked
> versions, but they give the path and code snippets from the actual IDLE
> directory.

If you do a directory-wide search for 'idlelib' you'll find that it is
mentioned in PyShell.py as well. I haven't tried this myself, so
please inform us whether or not this works :)

> 2. My idea
> [snip]

Awesome! I'll be glad to answer any questions you might have regarding
IDLE's internals.

An early pointer: IDLE doesn't currently allow unicode input, so
you'll have to rework that bit if you want unicode input support.

Good luck, and please keep us posted on developments,
- Tal

Re: An idea and a bug

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

Re: An idea and a bug

On 8/8/07, Jameson Chema Quinn <jquinn <at> cs.oberlin.edu> wrote:
>
>
> >
> > This is all very strange behavior.
> >
> > Please try the following:
> > 1. Replace all instances of 'idlelib' into 'jqidlelib', including
> > appearances inside strings. There should be two of these in PyShell.py
> > and two in idle.py. Also, make sure it doesn't appear in run.py either
> > (if it does, change it there too.)
> > 2. Rename/move the normal idlelib directory (temporarily)
> > 3. Close all existing instances of IDLE (and make sure no zombie
> > Python processes are still running in the background)
> > 4. Try running your version of IDLE again
> >
> > If IDLE still crashes, please send the tracebacks.
> >
> > - Tal
> >
>
> I think you misunderstand. The problem occurs, not when I run my script from
> the shell or from some other IDE, but when I run it from within IDLE. This
> makes it more understandable - but it is still a bug. Perhaps it's OK if you
> can't edit IDLE from within IDLE, but you should not get funny behaviour
> every time you load a module that happens to share a name with an IDLE
> module.
>
> Jameson
>

I think I understand the problem now - you're editing your version of
IDLE with the existing version, and you're having module importing
issues.

The problem is that when you run a Python script, the interpreter adds
the script's directory to the beginning of sys.path. This means the
when you do "import <module_name>", Python will go through the
directories in sys.path searching for a file by that name, and so it
will find first and use anything in the directory from where the
script was run. This is true for IDLE as well, and I can see now how
this can cause problems.

What you should do is run IDLE without adding its directory to
sys.path. Here's a quick way to do so from the command line:
python.exe -c "import idlelib.PyShell; idlelib.PyShell.main()"

Just run this from a directory which has nothing Python-related in it,
and you'll have no such importing issues. To completely ignore the
directory from which Python was run, use:
python.exe -c "import sys; del sys.path[0]; import idlelib.PyShell;
idlelib.PyShell.main()"

Another way would be to remove the directory from sys.path after IDLE
has started, inside IDLE's shell. However, it may not be the first
item in the sys.path list, because IDLE sometimes adds more
directories to sys.path.

Anyways, sorry for taking a while to understand the issue and hoping
the above helps,
- Tal

Cleaner Percolator.py implementation

I took the time to clean up the implementation of Percolator and add
some comments and doc-strings. I plan to do the same for Delegator
soon. I have found these to be very confusing and hard to understand,
although they could be a good piece of code to learn from. I hope I've
made the code more Pythonic :)

This version of Percolator inherits from Delegator (since a Percolator
"is a" Delegator, after all). I've also refactored the
Tk-Text-widget-specific stuff into a subclass, TkTextPercolator, which
is functionally equivalent to the original Percolator.

To use this in IDLE, use this file instead of Percolator.py (either
replace it or import this file instead of the original), and use the
TkTextPercolator class instead of Percolator (in EditorWindow.py).

I'm willing to post this as a patch on SF if there is any interest.

Comments are most welcome :)
- Tal

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

Re: IDLE getpass?

Tal Einat wrote:
>> 3) If I have to open a Tk window, how can I get it to appear on top of
>> the IDLE window?
> 
> IIRC this depends on your window manager. Tk's 'raise' command
> ('tkraise' in Python's Tkinter, because 'raise' is a Python keyword)
> just doesn't work on windows - this is a well known bug. I seem to
> recall that the TopLevel widgets' 'wm_deiconify' method has something
> to do with it... Try a Google Groups search on this issue + Tk, and
> you should find an answer.

Ok, I can't find anything to fix this. I've tried combinations of lower, 
lift, deiconify, iconify, update, overridedirect, ... but nothing I do 
can get a new Tk window to appear on top of IDLE.

This is very confusing for new students (and experts). I'll do whatever 
is necessary even it requires plugin or whatever. Can I lower IDLE?

Any ideas?

-Doug

Here's some code to help anyone see the problem:

# in IDLE on Windows XP:
import Tkinter
tl = Tkinter.Toplevel()
tl.update()
tl.raise()
...

I can't get the tl window to appear on top of IDLE.

>> Thanks for any additional hints,
>>
>> -Doug
> 
> Sorry for the unusually delayed reply!
> - Tal
> 

Extension to handle Cancel

I'm working on a plugin extension for IDLE that can run a test when 
Control+C is pressed. Unfortunately, Control+C (or <Cancel> in Tkinter 
bindings) is not handled as other key bindings are. Instead there is a 
cancel_callback in the pyshell instance that is called.

So, I've tried to replace the cancel_callback method from inside the 
extension (I have a working version from an external main---but it is 
really hacky). However, it looks like editwin.flist.pyshell doesn't 
exist yet when the constructor of the extension is called.

Is there any way for my extension module to have some code that gets 
called after the pyshell has been created?

-Doug

Sample code:

class ExtensionTest:
    def __init__(self, editwin):
       # works for other windows, after the shell is made, but:
       print editwin.flist.pyshell.cancel_callback, "does not exist yet"
       # when constructed for the shell

Running with subprocesses?

[Sorry for the barrage of questions... a new semester starting soon... :(]

It would be nice if an extension, or even a general running program, 
could look somewhere to see if IDLE is running with subprocesses. 
Something like PyShell.using_subprocess = 0. Is there a hack that would 
currently work to tell?

-Doug

Re: Running with subprocesses?

On 8/17/07, Douglas S. Blank <dblank <at> brynmawr.edu> wrote:
> [Sorry for the barrage of questions... a new semester starting soon... :(]
>
> It would be nice if an extension, or even a general running program,
> could look somewhere to see if IDLE is running with subprocesses.
> Something like PyShell.using_subprocess = 0. Is there a hack that would
> currently work to tell?
>

You can check flist.pyshell.interp.rpcclt. The debugging code in
PyShell.py checks that it is not None. The extra-safe version (used in
AutoComplete.py) is:

try:
    rpcclt = self.editwin.flist.pyshell.interp.rpcclt
except:
    rpcclt = None
if rpcclt:
    <with process>
else:
    <without subprocess>

This would be a nice addition to PyShell (or perhaps flist?). I'll add
this to my to-do list.

- Tal

Re: Extension to handle Cancel

On 8/16/07, Douglas S. Blank <dblank <at> brynmawr.edu> wrote:
> I'm working on a plugin extension for IDLE that can run a test when
> Control+C is pressed. Unfortunately, Control+C (or <Cancel> in Tkinter
> bindings) is not handled as other key bindings are. Instead there is a
> cancel_callback in the pyshell instance that is called.
>
> So, I've tried to replace the cancel_callback method from inside the
> extension (I have a working version from an external main---but it is
> really hacky). However, it looks like editwin.flist.pyshell doesn't
> exist yet when the constructor of the extension is called.
>
> Is there any way for my extension module to have some code that gets
> called after the pyshell has been created?
>
> -Doug
>
> Sample code:
>
> class ExtensionTest:
>     def __init__(self, editwin):
>        # works for other windows, after the shell is made, but:
>        print editwin.flist.pyshell.cancel_callback, "does not exist yet"
>        # when constructed for the shell

Hi Doug,

First off - Why Ctrl+C? It seems the simplest solution would be to
bind to a different hotkey, unless you deliberately want to override
the ability to use Ctrl+C to raise KeyboardInterrupt exceptions.

The answer is to just use editwin, and not flist.pyshell. When PyShell
is initialized, it will load the extension (the extensions are loaded
once per EditorWindow instance). You can set the 'enable_editor'
config option to False (or zero) for the extension to cause it to be
loaded only for the PyShell window and not for file editing windows.

If you want to be 100% sure, you can do 'isinstance(PyShell.PyShell,
editwin)' to ensure that the window is a shell window (so that things
don't go wrong if a user changes the 'enable_editor' config option).

- Tal