This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Author terry.reedy
Recipients ajaksu2, draghuram, eric.araujo, rickbking, terry.reedy
Date 2010-10-07.02:57:08
SpamBayes Score 5.55112e-17
Marked as misclassified No
Message-id <>
Since 'we' can reopen any closed issue, I will try to answer what I think you might be asking.

I closed this because of Daniel's suggestion coupled with the Richard disclaiming further interest and neither Raghuram nor any new responder saying anything more.

The issue title is a misstatement arising from the OP not noticing how to change the behavior. Anyone reopening this (or opening a new issue) would need to change the title to reflect what he thinks should be done. I will not do that because the naive change proposed in the thread seems unnecessary, while further investigation suggests that it may be wrong or insufficient.

The original post refers to use_rawinput as a 'module global value'. It is not that but a cmd.Cmd class data attribute that can be changed either for the class or an instance. It is one of 9 that might be so changed.

Looking at the patch with #405952 shows that Cmd.__init__ had no parameters and Cmd.cmdloop always read input with raw_input(), now renamed just input() (making the attribute name a bit obsolete). The replacement then was something like

                    if self.use_rawinput:
                            line = input(self.prompt)
                        except EOFError:
                            line = 'EOF'
                        sys.stdout.write(self.prompt) # note sys.,
                        sys.stdout.flush()            # not self. here
                        line = sys.stdin.readline()
                        if not len(line):
                            line = 'EOF'
                            line = line[:-1] # chop \n

The reason for this patch, which *almost* replicates raw_input(), was that raw_input and/or readline swallowed an exception, whereas the replacement code does not. I wonder:
1. Does input() still do the same and should it?
2. Is there something about cmd processing that this is the only use of input() where this exception swallowing is a problem?
3. If so, why not always use the replacement? Speed?
4. I am sort of asking whether this was/is really the right hack.

Someone later added completekey as an initialization parameter (rather than as a date attribute) and the following code

        if self.use_rawinput and self.completekey:
                import readline
                self.old_completer = readline.get_completer()
                readline.parse_and_bind(self.completekey+": complete")
            except ImportError:

I know nothing about readline and why it (apparently) requires the use of input(), but the point here is that setting use_rawinput to False disables completekey. This should be documented but I did not see such.

At the same or later time, someone added stdin and stdout parameters and change 'sys' to 'self' in the first snippet above. Given that these parameters appears useless when use_rawinput is True, why was use_rawinput not automatically set to false then? Blunder or subtle reason? Someone who proposes auto-resetting should try to find the name of the patch and/or commit author and ask.

It seems to me that all the process parameters should be handled uniformly. Make then all class attributes and let any be changed for instances as keyword attributes to __init__(). Given the conflict noted above, perhaps raise ValueError if someone makes contradictory changes.

So, Éric, if your question was academic, I would leave this closed.
If it was not, and you want to reopen, retitle, and assign it to yourself, go ahead.
Date User Action Args
2010-10-07 02:57:12terry.reedysetrecipients: + terry.reedy, draghuram, rickbking, ajaksu2, eric.araujo
2010-10-07 02:57:11terry.reedysetmessageid: <>
2010-10-07 02:57:10terry.reedylinkissue2571 messages
2010-10-07 02:57:08terry.reedycreate