[issue10328] re.sub[n] doesn't seem to handle /Z replacements correctly in all cases
New submission from Alexander Schmolck :
In certain cases a zero-width /Z match that should be replaced isn't.
An example might help:
re.compile('(?m)(?P[
\t]+\r*$)|(?P(?<=[^\n])\Z)').subn(lambda m:next('<'+k+'>' for
k,v in m.groupdict().items() if v is not None), 'foobar ')
this gives
('foobar', 1)
I would have expected
('foobar', 2)
Contrast this with the following behavior:
[m.span() for m in re.compile('(?P[
\t]+\r*$)|(?P(?<=[^\n])\Z)', re.M).finditer('foobar ')]
gives
[(6, 7), (7, 7)]
The matches are clearly not overlapping and the re module docs for sub say
"Return the string obtained by replacing the leftmost non-overlapping
occurrences of pattern in string by the replacement repl.", so I would have
expected two replacements.
This seems to be what perl is doing:
echo -n 'foobar ' | perl -pe 's/(?m)(?P[
\t]+\r*$)|(?P(?<=[^\n])\Z)/<$&>/g'
gives
foobar< ><>%
--
components: Regular Expressions
messages: 120499
nosy: Alexander.Schmolck
priority: normal
severity: normal
status: open
title: re.sub[n] doesn't seem to handle /Z replacements correctly in all cases
type: behavior
versions: Python 2.6, Python 3.1
___
Python tracker
<http://bugs.python.org/issue10328>
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1038909] pydoc method documentation lookup enhancement
Alexander Schmolck <[EMAIL PROTECTED]> added the comment: Ah, well nice to see this finally going somewhere, although I'm a bit puzzled as to why my patch was "clearly not implemented" :) Andy, wrt. to your points: 1. Yes, but see below. 2. Are you sure using inspect.ismethod is an improvement? I'm pretty sure I was aware of it and didn't use it for a reason -- from a superficial glance it appears to me that inspect.getmethod is just broken for this purpose. Or do you have a good reason why you'd like to exclude e.g. methods inherited from a builtin? I have no time to check right now, maybe the behavior of ismethod has changed or I remember it wrongly, but in general I think doc-lookup should be oblivious to changes that are transparent at the interface level and whether something is inherited from a builtin or not is should be considered as a mere implementation detail and not at all affect the documentation lookup. 3. I don't feel strongly about this but I'm personally not that keen on using comments as a substitute for docs -- I see no point in conflating these two mechanisms which serve quite different purposes (implementation elucidation vs interface description), especially if the comment is taken from *some other implementation*. 4. Certainly fine by me. 'as _ Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue1038909> _ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
