I think you shouldn't push it, Yury.
Most people here seem not to like it that much for many reasons.
Best,
Sven
On 23.10.2015 00:56, Yury Selivanov wrote:
Hi Barry,
On 2015-10-22 5:17 PM, Barry Warsaw wrote:
I think that it might be a good idea to state the following in PEP 8:
- use r'...' strings for raw strings that describe regular
expressions;
these strings might be highlighted specially in some editors.
- use R'...' strings for raw strings; editors*should not* highlight
any escaped characters in them.
Aside from other comments in this thread, I think it's generally a
bad idea to
codify semantics where there are none defined by the language. So r''
and R''
are equivalent. It would be like assigning different semantics or
syntax
highlighting for 'foo' and "foo".
The thing is that *a lot* of Python users have already made
the choice -- many tools (including GitHub) do highlight
r'' strings as regexps, and people love this feature, and
complain when it's not implemented in their tool of choice.
This is an extremely useful feature, since any regexp longer
than 20 characters is unreadable at a glance.
On the other hand, *a lot* of users are annoyed, when their
raw strings are highlighted as regexps (why \n is highlighted
as escaped?). Often that results not in just wrongly
highlighted raw strings, but in broken highlighting of
the whole source file [1].
In principle, there is no reason why *both* of these groups
of users can't use one tool and be happy. I propose to
establish a convention in PEP 8, explaining that, while both
literals are semantically equivalent,
- r'..' strings *should* be used for regexps,
- R'..' strings *should* be used for unstyled raw strings,
and tools *should* treat them as such.
All of this is merely about codifying the current status quo.
Thanks,
Yury
[1] https://gist.github.com/1st1/d3da5d69a9b6c088c26f
_______________________________________________
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/
Sven R. Kunze