Hi Martin,
On 03 septembre 13:13, Martin Pool wrote:
> We were recently debugging some code like this:
>
> re.compile('\\\\/')
>
> This is legal Python (equivalent to r'\\/') but possibly buggy. It would
> be safer and clearer to say r'\\/' if that's what you want - and the 're'
> manual highly recommends you should use raw strings here.
>
> In Python (unlike C, Perl, Python REs and most unix tools) backslashes
> followed by a non-special character in a string literal are passed through
> as backslashes, which in my small survey surprised many people.
>
> This patch gives a warning for string constants containing a backslash
> followed by a character with no escaped meaning. This seems like a good
> way to catch strings that ought to be raw strings.
sounds good to me. I've created a ticket for this feature [1], and pushed your
patch as a changeset so it gets into the review system. You should see it
linked to the ticket soon, as well as on http://hg-lab.logilab.org/review/pylint
(though I don't see it yet, and that doesn't seem normal so you may have to
wait one of our sysadmins intervention).
Besides a few changes (basically ChangeLog entry and link to ticket in the
commit message), it seems fine to me in a quick read. The only point being
message identifier: to avoid conflicts, the first two digits should represent
the checker, and you've used W0123 and W0124 while a checker ('base') already
use 01. See pylint/checkers/__init__ for attributed values. Related question:
do you thing a dedicated checker is worth it, rather than extending the
existing format checker?
All this discussion should be moved around the patch in the review system
though, and you'll probably need help here so don't hesitate to ask questions
here. I'm laking some time to go in deeper details right now.
Regarding your patch about symbolic warning names : I've also created a ticket
[2].
Your patch will be linked to the ticket automatically when pushed in our
repository
by adding "closes #104572" somewhere in the commit message. No changeset yet as
I've not been able to apply it:
[syt@scorpius pylint]$ patch -p1 < ~/attachment-0001.obj
patching file README
patching file checkers/base.py
patching file checkers/format.py
Hunk #1 succeeded at 37 (offset 2 lines).
Hunk #2 succeeded at 75 (offset 2 lines).
patching file checkers/imports.py
patching file checkers/misc.py
patching file doc/FAQ.txt
patching file doc/manual.txt
patching file lint.py
patching file reporters/__init__.py
patching file reporters/guireporter.py
patching file reporters/html.py
patching file reporters/text.py
patching file test/input/func_docstring.py
patching file test/unittest_lint.py
patching file utils.py
patch unexpectedly ends in middle of line
patch: **** malformed patch at line 529:
Using regular pull requests would definitly improve the process. I'll need more
time to read it, probably once everything is in the review process.
[1] http://www.logilab.org/ticket/104571
[2] http://www.logilab.org/ticket/104572
Many thanks you for your contribution anyway!
Cheers
--
Sylvain Thénault, LOGILAB, Paris (01.45.32.03.12) - Toulouse (09.54.03.55.76)
Formations Python, Debian, Méth. Agiles: http://www.logilab.fr/formations
Développement logiciel sur mesure: http://www.logilab.fr/services
CubicWeb, the semantic web framework: http://www.cubicweb.org
_______________________________________________
Python-Projects mailing list
Python-Projects@lists.logilab.org
http://lists.logilab.org/mailman/listinfo/python-projects
