Pyparsing

Latest version: v3.1.2

Safety actively analyzes 630217 Python packages for vulnerabilities to keep your Python projects secure.

Scan your dependencies

Page 7 of 17

2.2.1

-------------------------------
- Applied changes necessary to migrate hosting of pyparsing source
over to GitHub. Many thanks for help and contributions from hugovk,
jdufresne, and cngkaygusuz among others through this transition,
sorry it took me so long!

- Fixed import of collections.abc to address DeprecationWarnings
in Python 3.7.

- Updated oc.py example to support function calls in arithmetic
expressions; fixed regex for '==' operator; and added packrat
parsing. Raised on the pyparsing wiki by Boris Marin, thanks!

- Fixed bug in select_parser.py example, group_by_terms was not
reported. Reported on SF bugs by Adam Groszer, thanks Adam!

- Added "Getting Started" section to the module docstring, to
guide new users to the most common starting points in pyparsing's
API.

- Fixed bug in Literal and Keyword classes, which erroneously
raised IndexError instead of ParseException.

2.2.0

---------------------------
- Bumped minor version number to reflect compatibility issues with
OneOrMore and ZeroOrMore bugfixes in 2.1.10. (2.1.10 fixed a bug
that was introduced in 2.1.4, but the fix could break code
written against 2.1.4 - 2.1.9.)

- Updated setup.py to address recursive import problems now
that pyparsing is part of 'packaging' (used by setuptools).
Patch submitted by Joshua Root, much thanks!

- Fixed KeyError issue reported by Yann Bizeul when using packrat
parsing in the Graphite time series database, thanks Yann!

- Fixed incorrect usages of '\' in literals, as described in
https://docs.python.org/3/whatsnew/3.6.html#deprecated-python-behavior
Patch submitted by Ville Skyttä - thanks!

- Minor internal change when using '-' operator, to be compatible
with ParserElement.streamline() method.

- Expanded infixNotation to accept a list or tuple of parse actions
to attach to an operation.

- New unit test added for dill support for storing pyparsing parsers.
Ordinary Python pickle can be used to pickle pyparsing parsers as
long as they do not use any parse actions. The 'dill' module is an
extension to pickle which *does* support pickling of attached
parse actions.

2.1.10

-------------------------------
- Fixed bug in reporting named parse results for ZeroOrMore
expressions, thanks Ethan Nash for reporting this!

- Fixed behavior of LineStart to be much more predictable.
LineStart can now be used to detect if the next parse position
is col 1, factoring in potential leading whitespace (which would
cause LineStart to fail). Also fixed a bug in col, which is
used in LineStart, where '\n's were erroneously considered to
be column 1.

- Added support for multiline test strings in runTests.

- Fixed bug in ParseResults.dump when keys were not strings.
Also changed display of string values to show them in quotes,
to help distinguish parsed numeric strings from parsed integers
that have been converted to Python ints.

2.1.9

-------------------------------
- Added class CloseMatch, a variation on Literal which matches
"close" matches, that is, strings with at most 'n' mismatching
characters.

- Fixed bug in Keyword.setDefaultKeywordChars(), reported by Kobayashi
Shinji - nice catch, thanks!

- Minor API change in pyparsing_common. Renamed some of the common
expressions to PEP8 format (to be consistent with the other
pyparsing_common expressions):
. signedInteger -> signed_integer
. sciReal -> sci_real

Also, in trying to stem the API bloat of pyparsing, I've copied
some of the global expressions and helper parse actions into
pyparsing_common, with the originals to be deprecated and removed
in a future release:
. commaSeparatedList -> pyparsing_common.comma_separated_list
. upcaseTokens -> pyparsing_common.upcaseTokens
. downcaseTokens -> pyparsing_common.downcaseTokens

(I don't expect any other expressions, like the comment expressions,
quotedString, or the Word-helping strings like alphas, nums, etc.
to migrate to pyparsing_common - they are just too pervasive. As for
the PEP8 vs camelCase naming, all the expressions are PEP8, while
the parse actions in pyparsing_common are still camelCase. It's a
small step - when pyparsing 3.0 comes around, everything will change
to PEP8 snake case.)

- Fixed Python3 compatibility bug when using dict keys() and values()
in ParseResults.getName().

- After some prodding, I've reworked the unitTests.py file for
pyparsing over the past few releases. It uses some variations on
unittest to handle my testing style. The test now:
. auto-discovers its test classes (while maintining their order
of definition)
. suppresses voluminous 'print' output for tests that pass

2.1.8

----------------------------
- Fixed issue in the optimization to _trim_arity, when the full
stacktrace is retrieved to determine if a TypeError is raised in
pyparsing or in the caller's parse action. Code was traversing
the full stacktrace, and potentially encountering UnicodeDecodeError.

- Fixed bug in ParserElement.inlineLiteralsUsing, causing infinite
loop with Suppress.

- Fixed bug in Each, when merging named results from multiple
expressions in a ZeroOrMore or OneOrMore. Also fixed bug when
ZeroOrMore expressions were erroneously treated as required
expressions in an Each expression.

- Added a few more inline doc examples.

- Improved use of runTests in several example scripts.

2.1.7

----------------------------
- Fixed regression reported by Andrea Censi (surfaced in PyContracts
tests) when using ParseSyntaxExceptions (raised when using operator '-')
with packrat parsing.

- Minor fix to oneOf, to accept all iterables, not just space-delimited
strings and lists. (If you have a list or set of strings, it is
not necessary to concat them using ' '.join to pass them to oneOf,
oneOf will accept the list or set or generator directly.)

Page 7 of 17

© 2024 Safety CLI Cybersecurity Inc. All Rights Reserved.