Accepting request 721168 from devel:languages:python

- update to 2.4.2:
  - Updated the shorthand notation that has been added for repetition
    expressions: expr[min, max], with '...' valid as a min or max value
  - The defaults on all the `__diag__` switches have been set to False,
    to avoid getting alarming warnings. To use these diagnostics, set
    them to True after importing pyparsing.
  - Fixed bug introduced by the use of __getitem__ for repetition,
    overlooking Python's legacy implementation of iteration
    by sequentially calling __getitem__ with increasing numbers until
    getting an IndexError. Found during investigation of problem
    reported by murlock, merci!
  - Changed [...] to emit ZeroOrMore instead of OneOrMore.
  - Removed code that treats ParserElements like iterables.
  - Change all __diag__ switches to False.
- update to 2.4.1.1:
  - API change adding support for `expr[...]` - the original
    code in 2.4.1 incorrectly implemented this as OneOrMore.
    Code using this feature under this relase should explicitly
    use `expr[0, ...]` for ZeroOrMore and `expr[1, ...]` for
    OneOrMore. In 2.4.2 you will be able to write `expr[...]`
    equivalent to `ZeroOrMore(expr)`.
  - Bug if composing And, Or, MatchFirst, or Each expressions
    using an expression. This only affects code which uses
    explicit expression construction using the And, Or, etc.
    classes instead of using overloaded operators '+', '^', and
    so on. If constructing an And using a single expression,
    you may get an error that "cannot multiply ParserElement by
    0 or (0, 0)" or a Python `IndexError`.
  - Some newly-added `__diag__` switches are enabled by default,
    which may give rise to noisy user warnings for existing parsers.

OBS-URL: https://build.opensuse.org/request/show/721168
OBS-URL: https://build.opensuse.org/package/show/openSUSE:Factory/python-pyparsing?expand=0&rev=33

pyparsing-2.4.0.tar.gz

@@ -1,3 +0,0 @@
-version https://git-lfs.github.com/spec/v1
-oid sha256:1873c03321fc118f4e9746baf201ff990ceb915f433f23b395f5580d1840cb2a
-size 611956

pyparsing-2.4.2.tar.gz

@@ -0,0 +1,3 @@
+version https://git-lfs.github.com/spec/v1
+oid sha256:6f98a7b9397e206d78cc01df10131398f1c8b8510a2f4d97d9abd82e1aacdd80
+size 642860

python-pyparsing.changes

@@ -1,3 +1,118 @@
+-------------------------------------------------------------------
+Tue Aug  6 05:01:32 UTC 2019 - Thomas Bechtold <tbechtold@suse.com>
+
+- update to 2.4.2:
+  - Updated the shorthand notation that has been added for repetition
+    expressions: expr[min, max], with '...' valid as a min or max value
+  - The defaults on all the `__diag__` switches have been set to False,
+    to avoid getting alarming warnings. To use these diagnostics, set
+    them to True after importing pyparsing.
+  - Fixed bug introduced by the use of __getitem__ for repetition,
+    overlooking Python's legacy implementation of iteration
+    by sequentially calling __getitem__ with increasing numbers until
+    getting an IndexError. Found during investigation of problem
+    reported by murlock, merci!
+  - Changed [...] to emit ZeroOrMore instead of OneOrMore.
+  - Removed code that treats ParserElements like iterables.
+  - Change all __diag__ switches to False.
+- update to 2.4.1.1:
+  - API change adding support for `expr[...]` - the original
+    code in 2.4.1 incorrectly implemented this as OneOrMore.
+    Code using this feature under this relase should explicitly
+    use `expr[0, ...]` for ZeroOrMore and `expr[1, ...]` for
+    OneOrMore. In 2.4.2 you will be able to write `expr[...]`
+    equivalent to `ZeroOrMore(expr)`.
+  - Bug if composing And, Or, MatchFirst, or Each expressions
+    using an expression. This only affects code which uses
+    explicit expression construction using the And, Or, etc.
+    classes instead of using overloaded operators '+', '^', and
+    so on. If constructing an And using a single expression,
+    you may get an error that "cannot multiply ParserElement by
+    0 or (0, 0)" or a Python `IndexError`.
+  - Some newly-added `__diag__` switches are enabled by default,
+    which may give rise to noisy user warnings for existing parsers.
+- update to 2.4.1:
+  - A new shorthand notation has been added for repetition
+    expressions: expr[min, max], with '...' valid as a min
+  - '...' can also be used as short hand for SkipTo when used
+    in adding parse expressions to compose an And expression.
+  - '...' can also be used as a "skip forward in case of error" expression
+  - Improved exception messages to show what was actually found, not
+    just what was expected.
+  - Added diagnostic switches to help detect and warn about common
+    parser construction mistakes, or enable additional parse
+    debugging. Switches are attached to the pyparsing.__diag__
+    namespace object
+  - Added ParseResults.from_dict classmethod, to simplify creation
+    of a ParseResults with results names using a dict, which may be nested.
+    This makes it easy to add a sub-level of named items to the parsed
+    tokens in a parse action.
+  - Added asKeyword argument (default=False) to oneOf, to force
+    keyword-style matching on the generated expressions.
+  - ParserElement.runTests now accepts an optional 'file' argument to
+    redirect test output to a file-like object (such as a StringIO,
+    or opened file). Default is to write to sys.stdout.
+  - conditionAsParseAction is a helper method for constructing a
+    parse action method from a predicate function that simply
+    returns a boolean result. Useful for those places where a
+    predicate cannot be added using addCondition, but must be
+    converted to a parse action (such as in infixNotation). May be
+    used as a decorator if default message and exception types
+    can be used. See ParserElement.addCondition for more details
+    about the expected signature and behavior for predicate condition
+    methods.
+  - While investigating issue #93, I found that Or and
+    addCondition could interact to select an alternative that
+    is not the longest match. This is because Or first checks
+    all alternatives for matches without running attached
+    parse actions or conditions, orders by longest match, and
+    then rechecks for matches with conditions and parse actions.
+    Some expressions, when checking with conditions, may end
+    up matching on a shorter token list than originally matched,
+    but would be selected because of its original priority.
+    This matching code has been expanded to do more extensive
+    searching for matches when a second-pass check matches a
+    smaller list than in the first pass.
+  - Fixed issue #87, a regression in indented block.
+    Reported by Renz Bagaporo, who submitted a very nice repro
+    example, which makes the bug-fixing process a lot easier,
+    thanks!
+  - Fixed MemoryError issue #85 and #91 with str generation for
+    Forwards. Thanks decalage2 and Harmon758 for your patience.
+  - Modified setParseAction to accept None as an argument,
+    indicating that all previously-defined parse actions for the
+    expression should be cleared.
+  - Modified pyparsing_common.real and sci_real to parse reals
+    without leading integer digits before the decimal point,
+    consistent with Python real number formats. Original PR #98
+    submitted by ansobolev.
+  - Modified runTests to call postParse function before dumping out
+    the parsed results - allows for postParse to add further results,
+    such as indications of additional validation success/failure.
+  - Updated statemachine example: refactored state transitions to use
+    overridden classmethods; added <statename>Mixin class to simplify
+    definition of application classes that "own" the state object and
+    delegate to it to model state-specific properties and behavior.
+  - Added example nested_markup.py, showing a simple wiki markup with
+    nested markup directives, and illustrating the use of '...' for
+    skipping over input to match the next expression. (This example
+    uses syntax that is not valid under Python 2.)
+  - Rewrote delta_time.py example (renamed from deltaTime.py) to
+    fix some omitted formats and upgrade to latest pyparsing idioms,
+    beginning with writing an actual BNF.
+  - With the help and encouragement from several contributors, including
+    Matěj Cepl and Cengiz Kaygusuz, I've started cleaning up the internal
+    coding styles in core pyparsing, bringing it up to modern coding
+    practices from pyparsing's early development days dating back to
+    2003. Whitespace has been largely standardized along PEP8 guidelines,
+    removing extra spaces around parentheses, and adding them around
+    arithmetic operators and after colons and commas. I was going to hold
+    off on doing this work until after 2.4.1, but after cleaning up a
+    few trial classes, the difference was so significant that I continued
+    on to the rest of the core code base. This should facilitate future
+    work and submitted PRs, allowing them to focus on substantive code
+    changes, and not get sidetracked by whitespace issues.
+
 -------------------------------------------------------------------
 Thu Apr 18 13:30:30 UTC 2019 - Ondřej Súkup <mimi.vx@gmail.com>
 

python-pyparsing.spec

@@ -28,7 +28,7 @@
 %bcond_with test
 %endif
 Name:           python-pyparsing%{psuffix}
-Version:        2.4.0
+Version:        2.4.2
 Release:        0
 Summary:        Grammar Parser Library for Python
 License:        MIT AND GPL-2.0-or-later AND GPL-3.0-or-later