Terry J. Reedy <tjre...@udel.edu> added the comment:

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:
                        try:
                            line = input(self.prompt)
                        except EOFError:
                            line = 'EOF'
                    else:
                        sys.stdout.write(self.prompt) # note sys.,
                        sys.stdout.flush()            # not self. here
                        line = sys.stdin.readline()
                        if not len(line):
                            line = 'EOF'
                        else:
                            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:
            try:
                import readline
                self.old_completer = readline.get_completer()
                readline.set_completer(self.complete)
                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.

----------

_______________________________________
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/issue2571>
_______________________________________
_______________________________________________
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

Reply via email to