Philippe Verdy <verd...@wanadoo.fr> added the comment: Summary of your points with my responses :
> 1) it doesn't exist in any other implementation that I know; That's exactly why I proposed to discuss it with the developers of other implementations (I cited PCRE, Perl and PHP developers, there are others). > 2) if implemented as default behavior: > * it won't be backward-compatible; Wrong. This does not even change the syntax of regualr expressions themselves. > * it will increase the complexity; Wrong. All the mechanic is already implemented: when the parser will store string index positions for a matched group it will just have to append a pair in the list stored in MatchObject.group(index) (it will create the list if it is not ealready there, but it should be already initialized to an empty list by the compiler) when the flag.R is set, instead of overwriting the existing pair without wondering if there was already another occurence of the same capturing group. > 3) it will be a proprietary extension and it will reduce the compatibility with other implementations; Already suggested above. This will hovever NOT affect the compatibility of existing implementation that don't have the R flag. > 4) I can't think to any real word situation where this would be really useful. There are really a lot ! Using multiple split operations and multiple parsing on partly parsed regular expressions will not be a solution in many situations (think about how you would perform matches and using them that in 'vi' or 'ed' with a single "s/regexp/replacement/flag" instruction, if there's no extension with a flag and a syntax for accesing the individual elements the replacement string). ---------- _______________________________________ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue7132> _______________________________________ _______________________________________________ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
