Mailman 3 November 2017 - docs

[issue24896] It is undocumented that re.UNICODE affects re.IGNORECASE
by Leif Arne Storset 16 Nov '17

16 Nov '17

New submission from Leif Arne Storset: A non-ASCII string does not match a regular expression case-insensitively unless the UNICODE flag is set. This seems reasonable, but the documentation seems to imply that this is not the case. The example: import re # Does not match re.compile(u"неоднозначность", re.IGNORECASE) \ .findall(u"Неоднозначность") # Matches re.compile(u"неоднозначность", re.IGNORECASE | re.UNICODE) \ .findall(u"Неоднозначность") (In Python 3, it does not match if re.ASCII is given.) The documentation (2.7) says: re.UNICODE Make \w, \W, \b, \B, \d, \D, \s and \S dependent on the Unicode character properties database. (https://docs.python.org/2/library/re.html#re.UNICODE) My regex does not use any of those escapes, yet the regex changes behavior with the UNICODE flag. This leads to confusion when the regex doesn't match. The documentation is very specific about the behavior that changes with the flag, implying that behavior not mentioned is unaffected. Of course, it's easy to guess the correct (hopefully) solution. Still, I suggest changing the documentation to mention that re.IGNORECASE is affected. Looking at the source code, there seems to be further consequences (it mentions "Unicode locale") which may also warrant a mention. If you do want to avoid specifics, however, even a hand-wavy reference to something like "match according to Unicode" would help, because it implies that not only the escapes change behavior. In Python 3, there is a counterpart to the 2.7 problem: re.ASCII makes our Cyrillic string not match. Again, this behavior makes intuitive sense, but the documentation seems to indicate something different: re.ASCII Make \w, \W, \b, \B, \d, \D, \s and \S perform ASCII-only matching instead of full Unicode matching. This is only meaningful for Unicode patterns, and is ignored for byte patterns. … re.IGNORECASE Perform case-insensitive matching; expressions like [A-Z] will match lowercase letters, too. This is not affected by the current locale and works for Unicode characters as expected. re.ASCII does appear to affect re.IGNORECASE. Since this is the non-default case, however, I'm not sure it's worth calling it out. I'd be happy even if only the 2.7 docs change. ---------- assignee: docs@python components: Documentation messages: 248829 nosy: Leif Arne Storset, docs@python priority: normal severity: normal status: open title: It is undocumented that re.UNICODE affects re.IGNORECASE versions: Python 2.7, Python 3.4 _______________________________________ Python tracker <report(a)bugs.python.org> <http://bugs.python.org/issue24896> _______________________________________

8 14

[issue32024] Nominal decorator function call syntax is inconsistent with regular function calls
by Nick Coghlan 15 Nov '17

15 Nov '17

New submission from Nick Coghlan <ncoghlan(a)gmail.com>: Function calls in decorators are implemented as regular function calls, and hence permit the use of generator expressions as their sole argument without a second pair of parentheses. However, https://docs.python.org/3/reference/compound_stmts.html#function-definitions defines the permitted arguments differently from the way https://docs.python.org/3/reference/expressions.html#calls defines them, and thus technically considers a "function call as a decorator" to be a different construct from "a function call". The actual implementation treats these as the same thing, so clarification is needed as to whether it is the implementation or the language specification that should be updated to resolve the inconsistency. ---------- assignee: docs@python components: Documentation messages: 306205 nosy: docs@python, gvanrossum, ncoghlan, serhiy.storchaka priority: normal severity: normal stage: needs patch status: open title: Nominal decorator function call syntax is inconsistent with regular function calls type: behavior _______________________________________ Python tracker <report(a)bugs.python.org> <https://bugs.python.org/issue32024> _______________________________________

3 3

[issue31948] Broken MSDN links in msilib docs
by Berker Peksag 15 Nov '17

15 Nov '17

New submission from Berker Peksag <berker.peksag(a)gmail.com>: Most of the MSDN links in Doc/library/msilib.rst are broken: https://docs.python.org/3/library/msilib.html For example, the UuidToString link goes to https://msdn.microsoft.com/library?url=/library/en-us/rpc/rpc/uuidtostring.… But I believe the correct link should be https://msdn.microsoft.com/en-us/library/windows/desktop/aa379352(v=vs.85).… ---------- assignee: docs@python components: Documentation keywords: easy messages: 305593 nosy: berker.peksag, docs@python priority: normal severity: normal stage: needs patch status: open title: Broken MSDN links in msilib docs type: behavior versions: Python 3.6, Python 3.7 _______________________________________ Python tracker <report(a)bugs.python.org> <https://bugs.python.org/issue31948> _______________________________________

6 8

[issue15606] re.VERBOSE whitespace behavior not completely documented
by Serhiy Storchaka 14 Nov '17

14 Nov '17

Change by Serhiy Storchaka <storchaka+cpython(a)gmail.com>: ---------- resolution: -> fixed stage: patch review -> resolved status: open -> closed _______________________________________ Python tracker <report(a)bugs.python.org> <https://bugs.python.org/issue15606> _______________________________________

1 0

[issue15606] re.VERBOSE whitespace behavior not completely documented
by Serhiy Storchaka 14 Nov '17

14 Nov '17

Serhiy Storchaka <storchaka+cpython(a)gmail.com> added the comment: New changeset a2f1be0b5ba2bed49b7f94c026b541ff07e52518 by Serhiy Storchaka (Miss Islington (bot)) in branch '2.7': bpo-15606: Improve the re.VERBOSE documentation. (GH-4366) (#4395) https://github.com/python/cpython/commit/a2f1be0b5ba2bed49b7f94c026b541ff07… ---------- _______________________________________ Python tracker <report(a)bugs.python.org> <https://bugs.python.org/issue15606> _______________________________________

1 0

[issue15606] re.VERBOSE whitespace behavior not completely documented
by Serhiy Storchaka 14 Nov '17

14 Nov '17

Serhiy Storchaka <storchaka+cpython(a)gmail.com> added the comment: New changeset 14c1fe682f0086ec28f24fee9bf1c85d80507ee5 by Serhiy Storchaka (Miss Islington (bot)) in branch '3.6': bpo-15606: Improve the re.VERBOSE documentation. (GH-4366) (#4394) https://github.com/python/cpython/commit/14c1fe682f0086ec28f24fee9bf1c85d80… ---------- _______________________________________ Python tracker <report(a)bugs.python.org> <https://bugs.python.org/issue15606> _______________________________________

1 0

[issue15606] re.VERBOSE whitespace behavior not completely documented
by Roundup Robot 14 Nov '17

14 Nov '17

Change by Roundup Robot <devnull(a)psf.upfronthosting.co.za>: ---------- pull_requests: +4343 _______________________________________ Python tracker <report(a)bugs.python.org> <https://bugs.python.org/issue15606> _______________________________________

1 0

[issue15606] re.VERBOSE whitespace behavior not completely documented
by Roundup Robot 14 Nov '17

14 Nov '17

Change by Roundup Robot <devnull(a)psf.upfronthosting.co.za>: ---------- pull_requests: +4342 _______________________________________ Python tracker <report(a)bugs.python.org> <https://bugs.python.org/issue15606> _______________________________________

1 0

[issue15606] re.VERBOSE whitespace behavior not completely documented
by Serhiy Storchaka 14 Nov '17

14 Nov '17

Serhiy Storchaka <storchaka+cpython(a)gmail.com> added the comment: New changeset b0b44b4b3337297007f5ef87220a75df204399f8 by Serhiy Storchaka in branch 'master': bpo-15606: Improve the re.VERBOSE documentation. (#4366) https://github.com/python/cpython/commit/b0b44b4b3337297007f5ef87220a75df20… ---------- _______________________________________ Python tracker <report(a)bugs.python.org> <https://bugs.python.org/issue15606> _______________________________________

1 0

Is this a BUG?
by glyph 12 Nov '17

12 Nov '17

Python Ver 2.7 and v3.6.2:5fd33b5 >>> p = True >>> q = False >>> p != q True # YES >>> p == q False # YES >>> ( p != q ) != p False # YES >>> p != ( q != p ) False # YES >>> p != q != p True # ??? >>>

1 0