Terry J. Reedy <tjre...@udel.edu> added the comment:
IDLE is sufficiently undocumented that I think we may, *if necessary*, treat
the details of 'expected behavior' as undefined, or look to other programs for
guidance. Certainly, 'crash' is unexpected and undesired ;-).
Without "[] Regular expression" checked, I expect a simple 'normal mode' "find
the literal string and replace with literal string" behavior. This is how
Notepad and Notepad++ work. Neither has any problem with trailing '\'. The main
'special chars' I noticed are those normally significant to dialogs: the [Tab]
key advances focus, [Enter] key executes the currently highlighted command.
(The other two programs start with [Find] rather than [Replace] selected, but
that is a minor and visually noticeable detail.) ^C and ^V work as expected in
the entry boxes, other control chars beep.
In this mode, it is an implementation detail that the re module is used, and it
should be transparent that it is. So 'backreferences' are meaningless. But in
regular expression mode, they should act as an experienced re user would
expect. (What that is, I an not sure, as I am not such ;-).
Notepad++ separates 'Regular expression' from the other options and has a boxed
three-button radio group
|-Search mode-------------------------|
| () Normal |
| () Extended (\n, \r, \t, \0, \x...) |
| () Regular expression |
|-------------------------------------|
These amount to treating the find/replace entries as uninterpreted string
literals (as with input()*), cooked \-interpreted string literals, and as (raw
literal) relational expressions. We could consider Extended mode as a new
feature.
* While raw string literals do not allow training '\', the input function does
(in the standard interpreter window)
>>> print(input())
abc\
abc\
However, this does *not* work in IDLE 3.2.2, Win 7:
>>> print(input())
abd\ [hit Enter here]
[which IDLE echoes here]
[must Enter again]
[which IDLE echoes again]
>>> [to get new prompt]
>>> x=input()
abc\
>>> x
''
Entering "a\bc" is also messed up:
>>> x=input()
a\bc
>>> x
''
>>> x=input()
a\bc
>>> x
'a\\bc'
The difference between the two above involves the IDLE history mechanism, which
(wrongly, in my view) treats response to input() as part of the statement.
I wonder if this is related to the current bug. Does the replace dialog use
input()? Or is input entirely handled by tk, and should I open another report?
Ezio's other point:
'''
m = prog.match(chars, col)
if not prog:
return False
...
I think that "if not prog" in the snippet I pasted should be "if not m".
Pattern objects are always True (I assume prog is always a pattern object).'''
I would guess that you are correct and this should be fixed also.
----------
_______________________________________
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/issue13052>
_______________________________________
_______________________________________________
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
