Providing 'default' value with raw_input()?
Alex Martelli
aleax at mail.comcast.net
Fri Dec 23 11:33:34 EST 2005
planetthoughtful <planetthoughtful at gmail.com> wrote:
> Thank you for the suggestion, I'll have a look at this as an
> alternative.
>
> I must admit, it seems a little like a 'kludge', though -- but probably
> a necessary one, given the limitations of the OS.
Hmmm, what OS? The recipe I mentioned is probably the best approach on
Windows, MacOS, Linux, and other Unix variants -- what other OS do you
have in mind, that would let you submit to the user hundreds of
characters for editing without in fact using an editor?
> I'm assuming os.popen() keeps track of when the editor closes? Or would
It has to, because it needs to supply all the subprocess's output as the
contents of the file object it returns, and it couldn't be sure it has
all of the output until the subprocess has finished. There are, of
course, other ways to control sub-processes (Python 2.4's subprocess
module, in particular).
> I have to manually fire an 'ok, now update the record in the db' event
> after editing the value?
In some situations it may be impractical to rely on the editor closing;
for example, the user's favorite editor might be a multitab one that's
big, heavy, and slow to start, so that the user doesn't close the whole
process but rather just a specific tab. In such cases, unless you can
build in some hook specific to the user's favorite editor (so you can
know when a specific tab/file is done getting edited), you may end up
requiring the user to press enter at your prompt to indicate he or she's
done editing, or some such semi-kludge. I cannot think of a
sufficiently general solution, given the variety of editors around, to
just magically divine the crucial "done with editing" condition...
Alex
More information about the Python-list
mailing list