Overview
Request 721168 accepted
- 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.
Request History
tbechtold created request
- 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.
factory-auto added opensuse-review-team as a reviewer
Please review sources
factory-auto accepted review
Check script succeeded
licensedigger accepted review
ok
staging-bot set openSUSE:Factory:Staging:F as a staging project
Being evaluated by staging project "openSUSE:Factory:Staging:F"
staging-bot accepted review
Picked openSUSE:Factory:Staging:F
dimstar accepted review
dimstar_suse accepted review
ready to accept
dimstar_suse approved review
ready to accept
dimstar_suse accepted request
Accept to openSUSE:Factory