Changing UNIX tty driver keys -- Suggested changes to "termios" module
Should I add an RFE to SourceForge too? I'd like a wide audience in case
someone has enough experience to comment or is solving the same problem.
I'm using the urwid library which uses curses. On my system (Mac OS 10.3.7)
I specifically have ncurses. The programs I'm running turn off echoing and
set raw mode but don't disable interrupts. For development purposes I like
having interrupts, but my preferred keystrokes (WordStar) conflict with the
tty driver's use of ^C, ^Z, ^V, and maybe other keys.
Here's a piece of code based on the example in section 8.8.1 of the Python
Library Reference. It doesn't handle ^V yet.
--
termios_cc = 6 # magic index -- not 4 which is position
# in the C struct
termios__POSIX_VDISABLE = '\xff' # signals are set to this
# when they don't corres-
# pond to any char.
fd = sys.stdin.fileno()
oldterm = termios.tcgetattr(fd)
oldterm_int = oldterm[termios_cc][termios.VINTR]
oldterm_quit = oldterm[termios_cc][termios.VQUIT]
if ord(oldterm_int) != 3: # ^C
sys.exit("interrupt char isn't ^C")
if ord(oldterm_quit) != 28: # ^\
sys.exit("quit char isn't ^\\")
# no way to check whether applications (telnet, screen)
# are looking for ^^
# no check yet for any signals set to ^^
newterm = termios.tcgetattr(fd)
newterm[termios_cc][termios.VQUIT] = chr(30) # ^^
newterm[termios_cc][termios.VINTR] = chr(28) # ^\
try:
termios.tcsetattr(fd, termios.TCSADRAIN, newterm)
self.ui.run_wrapper(self.run)
finally:
termios.tcsetattr(fd, termios.TCSADRAIN, oldterm)
--
I'd like to handle errors and race conditions better, but I don't know what
kinds can happen in practice. I'd also like to make the code work on other
versions of UNIX.
Easy suggested improvements to the library: Define _POSIX_VDISABLE and names
for the fields of the struct, so that termios__POSIX_VDISABLE and termios_cc
become termios._POSIX_VDISABLE and termios.cc.
Harder improvements: Some functions that abstract the things I'm doing
(checking the current characters, changing a group of them in one operation).
I assume two signals should never be set to the same character, unless they
are disabled. Is it possible to make the state variables invisible? Is that
a good idea?
Thanks,
-- Derek
--
http://mail.python.org/mailman/listinfo/python-list
Finding the type of indexing supported by an object?
Here are two functions.
def invert_dict_to_lists(dict):
lists = {}
for key in dict:
value = dict[key]
if not value in lists:
lists[value] = [key]
else:
lists[value].append(key)
return lists
def invert_list_to_lists(list):
lists = {}
for key in range(len(list)):
value = list[key]
if not value in lists:
lists[value] = [key]
else:
lists[value].append(key)
return lists
They are the same except for the expression in "for key in ...". Can they
be combined into one function? How can I determine if the argument is
like a list (with numeric indices that are not stored in the list) or a dict
(with arbitrary keys that are stored)? I said "object" in the subject,
but I want to support Python primitive types, class instances, extension
module types (array, dictproxy, dbm, gdbm, etc.), and any future types.
I've thought about looking for keys(), looking for the special method names
that allow you to override indexing behavior, and looking at the class or
type of the object. I could be wrong, but I don't think any of those
strategies will work with all arguments.
Thanks,
-- Derek
--
http://mail.python.org/mailman/listinfo/python-list
Creating a subpackage of a built-in module?
Can I add my own subpackages to modules that are written in C? I've put /Users/dpeschel/lib/python into my PYTHONPATH variable. Inside there, I've created a termios directory, and inside termios I've created __init__.py and signals.py. Now "import termios.signals" works, but "import termios" only appears to work (it has no effect). Do I have to do something sneaky in __init__.py to find the original module, or is there a better way? -- http://mail.python.org/mailman/listinfo/python-list
Re: Finding the type of indexing supported by an object?
In article <[EMAIL PROTECTED]>, Alex Martelli wrote: >Derek Peschel <[EMAIL PROTECTED]> wrote: >> They are the same except for the expression in "for key in ...". Can they >> be combined into one function? How can I determine if the argument is > >They can easily be refactored, if that's what you mean: No, that isn't what I mean. I wanted _one_ function that works with a wide variety of objects -- anything that has a finite number of keys you can iterate over, with each key mapping to a finite number of values, and the key iteration and value lookup referentially transparent. This hypothetical function would have to do some checking of the argument type, but hopefully as little as possible. It should work with object types invented after it was written. Reading everyone's replies, especially yours and Fredrik Lundh's, I realized I've been thinking of the whole problem in Smalltalk (or possibly Ruby) terms. Smalltalk and Ruby use inheritance to describe some properties of objects. Python has many primitive types that aren't related to eaach other. I thought that testing for methods might get the properties I wanted, but you two pointed out that the method writer has too much latitude. Do you think the generic-function idea is still useful? At the moment I only need to invert dicts and lists. Is subclassing dict and list considred good style? (I see I can't add methods to dict and list directly.) >I've also performed a few other minor enhancements (never name things >dict or list because that hides the builtin types, use xrange vs range). OK, I'll remember those points. The argument names are a style I got from my Ruby code, and possibly not a good idea there either. >I have not changed the 4 lines in the if/else though I don't like them >(if not.../else is a very confusing construct -- at a minimum I'd >rephrase it as if/else swapping the bodies of the two clauses). It used if/else originally. Then I swapped the parts of the conditional to make the inversion function match another function (that takes a key, old value, and new value, and makes the change in a sequence and in its inverted form). To me the swapped version made some sense in the second function, because of the layout of the function as a whole, but you have a point that if not/else is rarely (never?) clear. >If you want to add a generic form accepting either lists or dicts you >need a try/except statement inside it, e.g.: Is that a reliable way to get the properties I wanted? RADLogic Pty. Ltd. added a two-way dict package to the Cheese Shop. It requires that the mapping be one-to-one, which won't work for me. It sub- classes dict, and requires that keys and values be hashable. -- Derek -- http://mail.python.org/mailman/listinfo/python-list
Re: Finding the type of indexing supported by an object?
In article <[EMAIL PROTECTED]>, Peter Otten wrote: >Instead of the (unreliable) introspection approach you could let the client >code decide: See my reply to Alex Martelli's post, where I explain my original desire for one function that works with a wide variety of present and future object types. Your solution accomplishes that, but only by forcing the caller to convert the argument to a list of pairs. If the caller knows the type it's going to pass down, that's easy. If the caller doesn't know, your approach doesn't seem any easier than mine. In practice, with my needs of inverting dicts and lists, your solution might not be a bad one. -- Derek -- http://mail.python.org/mailman/listinfo/python-list
