The behaviour of the direction keys on the numpad is
inconsistent when numlock is turned off. 
Home/End/PgUp/PgDn and the arrow keys work fine in some
applications (gedit), but do not work in Python's idle.
By not work, I mean: input is silently dropped.

How reproducible:
Always

Steps to Reproduce:
1. Turn off numlock.
3. Open gedit, type in garbage, use direction keys on
numpad to move around.
4. Open idle, type in garbage, attempt to use direction
keys on numpad to move around. It fails.    

Actual Results:  Intense frustration for people who
have been using the numeric keypad as direction keys
for decades!

Expected Results:  When numlock is off, the direction
keys on the numpad should function in the same manner
as the dedicated direction keys.

I am reporting this for Python 2.3, but I had exactly
the same problem in Python 2.2.

This problem has also been reported to RedHat, see 

http://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=136600.

Logged In: YES 
user_id=1167414

In RedHat bugzilla, this problem was reported for fedora
under x86_64.  I have been having the problem on i386 using
CentOS-3, which is similar to RHEL 3.  So the problem seems
to apply across Linux architectures, but not across
platforms.  It may be a RedHat problem across architectures.  

Logged In: YES 
user_id=80475

Kurt, as far as I can tell, there is nothing in Tkinter that
gives us any control over this.  If you concur, please mark
this as 3rd party and/or platform specific and close it.

Logged In: YES 
user_id=149084

Yes, if OP wants to pursue it, he should take it up with the
Tk people:   http://tcl.sourceforge.net/

Logged In: YES 
user_id=1167414

> Yes, if OP wants to pursue it, he should take it up with the 
Tk people:   http://tcl.sourceforge.net/ 
 
1) Who is OP?   
 
2) Is this ball in my court or someone else's? 
 
Thanks, 
 
netvigator aka Rick Graves 

Logged In: YES 
user_id=469548

OP = opening poster. So yes, the ball is in your court. :)

Logged In: YES 
user_id=1167414

I posted the "bug" on the Tk list as suggested.  Today I got this: 
 
begin quote 
 
>Comment By: Jeffrey Hobbs (hobbs) 
Date: 2004-12-24 11:25 
 
Message: 
Logged In: YES  
user_id=72656 
 
This is not a bug, but rather just that Tk differentiates 
between the regular arrow up and keypad up on some systems, 
depending on how their system keymaps operate.  The first is 
<Up> and the second is <KP_Up> on Linux, but both are <Up> 
on Windows.  This has always been the case for KP_Enter as 
well.  The fact that Windows doesn't separate these is by 
design, but has also caused people to want them separated 
(see TIP http://www.tcl.tk/cgi-bin/tct/tip/158.html). 
 
IOW, the bindings should be on <Up> and <KP_Up> if they are 
to be considered equivalent in an app.  This is best handled 
by using virtual events (like <<Up>>) and adding the 
specific event names that you want to apply to it.  Please 
filter this back to the other reports. 
 
---------------------------------------------------------------------- 
 
You can respond by visiting:  
https://sourceforge.net/tracker/?func=detail&atid=112997&aid=1090719&group_id=12997 
 
end quote 
 
Would  someone please either reopen this or let me know what my 
next step should be. 
 
Thanks, 
 
Rick 

Logged In: YES 
user_id=149084

OK, thanks for the leg work.  I'll take a further look.

My keyboards are IBM Model M SpaceSavers.  I don't
do keypads...  :-)

Confirmed in trunk, the <KP_Up> (80) events show in a terminal if one
adds some print-based debug help.

Unfortunately this is not that easy for us, while we could add some code
like this:

import Tkinter

text = Tkinter.Text()
text.event_add("<<Up>>", "<Key-Up>")
text.event_add("<<Up>>", "<Key-KP_Up>")
text.bind_class("Text", "<<Up>>", text.bind_class("Text", "<Key-Up>"))
text.pack()
text.mainloop()

it won't work as most would expect. When numlock is on, it would still
move one line up. We could change it to fix this problem, but then we
would be using tk::TextUpDownLine which is marked as unsupported
(basically everything that could help us in such situations is marked as
unsupported).
I will be asking someone about all these unsupported commands.

> When numlock is on, it would still
> move one line up. We could change it to fix this problem, but then we
> would be using tk::TextUpDownLine which is marked as unsupported
> (basically everything that could help us in such situations is marked as
> unsupported).

Ah yes, here is something that would do what we wanted (for "up" only):

import Tkinter

def my_up(event):
    widget = event.widget
    if event.keysym == 'KP_Up' and event.state & 16:
        widget.tk.call('tk::TextInsert', widget, event.char)
        return "break"
    pos = widget.tk.call('tk::TextUpDownLine', widget, -1)
    widget.tk.call('tk::TextSetCursor', widget, pos)

text = Tkinter.Text()
text.event_add("<<Up>>", "<Key-Up>")
text.event_add("<<Up>>", "<Key-KP_Up>")
text.bind_class("Text", "<<Up>>", my_up)
text.pack()
text.mainloop()

I verified that this issue does not affect Windows. What about Mac? A patch might best be system-specific in only being active on systems that need it.

The lack of complaints other than by one person suggests that it is not a high priority among linux users -- or that they are all resigned to flakey behavior, or that some other linux apps also do not recognize numlock-off keypad keys.

Summary: (Graves, msg23356, 2004-12-24) tk event for keypad keys depends on system keymap.  Windows: numlock off, keypad up (8) is <up>.  Linux: same is <kp-up> and Text does *not* see this as <up>
(Polo, msg86364, 2009-04-23) Workaround is to capture both events and tk:call multiple upsupported internal tk functions.

In the absence of more contemporary complaints by Linux users, closing.