[issue12862] ConfigParser does not implement "comments need to be preceded by a whitespace character" correctly
New submission from Daniel Fortunov :
ConfigParser does not implement "comments need to be preceded by a whitespace
character" correctly and in most cases will treat a value beginning with a
comment character as a comment, even though it is not preceded by a whitespace
character.
The ConfigParser documentation states:
"""
Comments may appear on their own in an otherwise empty line, or may be entered
in lines holding values or section names. In the latter case, they need to be
preceded by a whitespace character to be recognized as a comment.
"""
This suggests that in the following configuration file, the value of 'password'
would be read as ';23bUx1'.
[test_config]
password=;23bUx1
username=bar
In fact, there appears to be a bug in the following code within
RawConfigParser._read():
if vi in ('=', ':') and ';' in optval:
# ';' is a comment delimiter only if it follows
# a spacing character
pos = optval.find(';')
if pos != -1 and optval[pos-1].isspace():
optval = optval[:pos]
optval = optval.strip()
For the example file above, vi==';' and optval==';23bUx1\r'. pos therefore
takes the value 0, and the second part of the compound if statement which
checks if the preceding character is a space ends up looking at optval[-1] --
the last character in optval -- which is \r, since it has not yet been stripped.
I think this can be resolved by changing the line:
if pos != -1 and optval[pos-1].isspace():
to:
if pos > 0 and optval[pos-1].isspace():
Thus, the "if preceded by a space" case is only considered if the comment
character appears *after* the first character in the value. (And if it appears
as the very *first* character, then by definition it cannot be preceded by a
space!)
A rather fragile workaround (which works only if there is only one single value
affected by this bug) would be to ensure that the affected value is defined on
the last line of your config file, the file does not end with a carriage
return. In this case, the optval[-1] would return a non-whitespace character
and prevent the value being considered a comment.
The above analysis pertains to Python 2.7.2, and I see that the implementation
has been re-written in python 3 so this bug doesn't seem to exist there.
--
components: Library (Lib)
messages: 143230
nosy: DanielFortunov
priority: normal
severity: normal
status: open
title: ConfigParser does not implement "comments need to be preceded by a
whitespace character" correctly
type: behavior
versions: Python 2.7
___
Python tracker
<http://bugs.python.org/issue12862>
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue45347] datetime subject to rounding?
Change by Daniel Fortunov : -- nosy: +dfortunov ___ Python tracker <https://bugs.python.org/issue45347> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue40895] weakref documentation contains cautions about dictionary mutation problems that have been solved in the implementation
New submission from Daniel Fortunov : The doccumentation at https://docs.python.org/3.10/library/weakref.html cautions that the WeakKeyDictionary and WeakValueDictionary are susceptible to the problem of dictionary mutation during iteration. These notes present the user with a problem that has no easy solution. I dug into the implementation and found that fortunately, Antoine Pitrou already addressed this challenge (10 years ago!) by introducing an _IterationGuard context manager to the implementation, which delays mutation while an iteration is in progress. I asked for confirmation and Antoine agreed that these notes could be removed: https://github.com/python/cpython/commit/c1baa601e2b558deb690edfdf334fceee3b03327#commitcomment-39514438 -- assignee: docs@python components: Documentation messages: 370860 nosy: dfortunov, docs@python priority: normal severity: normal status: open title: weakref documentation contains cautions about dictionary mutation problems that have been solved in the implementation versions: Python 3.10 ___ Python tracker <https://bugs.python.org/issue40895> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue40895] weakref documentation contains cautions about dictionary mutation problems that have been solved in the implementation
Change by Daniel Fortunov : -- keywords: +patch pull_requests: +19901 stage: -> patch review pull_request: https://github.com/python/cpython/pull/20687 ___ Python tracker <https://bugs.python.org/issue40895> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue31254] WeakKeyDictionary/Mapping doesn't call __missing__
Change by Daniel Fortunov : -- keywords: +patch nosy: +dfortunov nosy_count: 4.0 -> 5.0 pull_requests: +19900 stage: -> patch review pull_request: https://github.com/python/cpython/pull/20687 ___ Python tracker <https://bugs.python.org/issue31254> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue7105] weak dict iterators are fragile because of unpredictable GC runs
Change by Daniel Fortunov : -- nosy: +dfortunov nosy_count: 15.0 -> 16.0 pull_requests: +19902 pull_request: https://github.com/python/cpython/pull/20687 ___ Python tracker <https://bugs.python.org/issue7105> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue35226] mock.call equality surprisingly broken
Change by Daniel Fortunov : -- nosy: +dfortunov ___ Python tracker <https://bugs.python.org/issue35226> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue36582] collections.UserString encode method returns a string
Daniel Fortunov added the comment: I'll pick this up in the PyCon US 2019 sprint this afternoon. -- nosy: +dfortunov ___ Python tracker <https://bugs.python.org/issue36582> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue36582] collections.UserString encode method returns a string
Change by Daniel Fortunov : -- keywords: +patch pull_requests: +13051 stage: needs patch -> patch review ___ Python tracker <https://bugs.python.org/issue36582> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue36582] collections.UserString encode method returns a string
Daniel Fortunov added the comment: PR submitted here: https://github.com/python/cpython/pull/13138 Rather than adding three different tests for the different code paths I chose to collapse the three different code paths by surfacing the underlying str.encode() defaults in the method signature of UserString.encode(), taking it down to a one-line implementation. @xtreak: Thanks for the super-helpful triage and failing test case! -- ___ Python tracker <https://bugs.python.org/issue36582> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue36824] Refactor str tests to reflect that str and unicode are merged in Python 3
New submission from Daniel Fortunov : Unit tests of `str` and related types (e.g. `UserString`) contain nomenclature and structure that dates back to the Python 2 distinction between `str` and `unicode`. Previously it was undesirable to disturb the structure of these tests too much as this would complicate the merging of bug fixes back to Python 2, however with Python 2 drawing near to end-of-life this is perhaps less of a concern. I would propose the following changes as a start: - Rename test_unicode.py to test_str.py, and `UnicodeTest` class to `StrTest` (to reflect the type that is now being tested) - Remove `MixinStrUnicodeUserStringTest` class and move its tests into `CommonTest` (The comment for this class says # additional tests that only work for # stringlike objects, i.e. str, UserString but in the absence of `unicode` the `CommonTest` class is also only used for these two types now.) - Promote tests from the current `UnicodeTest` class to `CommonTest` where it makes sense to do so; remove checks that no longer make sense. (e.g. checks around mixed `str`/`unicode` arguments that are all just `str` now) Maybe the duplicative `checkequalnofix()` method can also go away now? - The `BadSeq1` helper class is not used because the corresponding check was commented out in 2007. Either reinstate the check, or remove this class. I'm happy to submit a PR for this, but just wanted to get some feedback before making the changes. -- components: Library (Lib) messages: 341685 nosy: dfortunov, ncoghlan, xtreak priority: normal severity: normal status: open title: Refactor str tests to reflect that str and unicode are merged in Python 3 type: enhancement versions: Python 3.8 ___ Python tracker <https://bugs.python.org/issue36824> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue36824] Refactor str tests to reflect that str and unicode are merged in Python 3
Daniel Fortunov added the comment: Agreed. This functionality is in `BaseTest` (which is the base for `CommonTest`) and I don't propose to change this. -- ___ Python tracker <https://bugs.python.org/issue36824> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue36824] Refactor str tests to reflect that str and unicode are merged in Python 3
Daniel Fortunov added the comment: PS opened here: https://github.com/python/cpython/pull/13172 I've tried to break down the changes into individual steps, with justification in commit messages. Happy to collapse these down into fewer commits before merge if preferred. I haven't done the "Promote tests from the current `UnicodeTest` class to `CommonTest`" portion yet, but I'm running out of sprint time so I wanted to submit what I have. I believe these changes are suitable for merge to master, but keen to hear feedback :-) -- ___ Python tracker <https://bugs.python.org/issue36824> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue36824] Refactor str tests to reflect that str and unicode are merged in Python 3
Change by Daniel Fortunov : -- keywords: +patch pull_requests: +13088 stage: -> patch review ___ Python tracker <https://bugs.python.org/issue36824> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue25436] argparse.ArgumentError missing error message in __repr__
Daniel Fortunov added the comment: As Paul points out, Python 3 gives a more sensible default repr so this becomes a non-issue. Closing... -- stage: patch review -> resolved status: open -> closed versions: +Python 2.7 -Python 3.4, Python 3.5, Python 3.6 ___ Python tracker <https://bugs.python.org/issue25436> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue25436] argparse.ArgumentError missing error message in __repr__
New submission from Daniel Fortunov: ArgumentError's __init__() fails to call super(), meaning that the base exception doesn’t get a message, and thus repr() always returns “argparse.ArgumentError()” with no message. Not very helpful if that repr gets logged, or included in another error message :-( I've attached a patch that fixes this, and adds corresponding tests. -- components: Library (Lib) files: cpython_ArgumentError_repr.patch keywords: patch messages: 253160 nosy: dfortunov priority: normal severity: normal status: open title: argparse.ArgumentError missing error message in __repr__ Added file: http://bugs.python.org/file40813/cpython_ArgumentError_repr.patch ___ Python tracker <http://bugs.python.org/issue25436> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue25436] argparse.ArgumentError missing error message in __repr__
Daniel Fortunov added the comment: Paul, Thanks for your comprehensive reply. I agree with everything you've said and the reason I've taken so long to reply is that I've been racking my brains to remember exactly how I came across this scenario. I did at some point see an ArgumentError but I've forgotten the exact scenario. Since I can't see any of our internal codebase explicitly raising an ArgumentError, then I can only assume this must have just been a frustration I encountered when debugging into argparse code. So I'll reformulate the question: Do you think it's worthwhile to make ArgumentError's repr() more useful for the purposes of interactive debugging alone? Regards, Dani PS: I agree with your suggestion that you could achieve the same effect by defining a `__repr__` method for `ArgumentError`. I just thought that calling `super()` was more idiomatic. -- ___ Python tracker <http://bugs.python.org/issue25436> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
