Subject: CVS commit: pkgsrc/devel/py-pyparsing
From: Leonardo Taccari
Date: 2016-02-16 14:41:15
Message id: 20160216134115.C8FA5FBB7@cvs.NetBSD.org

Log Message:
Update devel/py-pyparsing to 2.1.0.

Changes:
Version 2.1.0 - February, 2016
------------------------------
- Modified the internal _trim_arity method to distinguish between
  TypeError's raised while trying to determine parse action arity and
  those raised within the parse action itself. This will clear up those
  confusing "<lambda>() takes exactly 1 argument (0 given)" error
  messages when there is an actual TypeError in the body of the parse
  action. Thanks to all who have raised this issue in the past, and
  most recently to Michael Cohen, who sent in a proposed patch, and got
  me to finally tackle this problem.

- Added compatibility for pickle protocols 2-4 when pickling ParseResults.
  In Python 2.x, protocol 0 was the default, and protocol 2 did not work.
  In Python 3.x, protocol 3 is the default, so explicitly naming
  protocol 0 or 1 was required to pickle ParseResults. With this release,
  all protocols 0-4 are supported. Thanks for reporting this on StackOverflow,
  Arne Wolframm, and for providing a nice simple test case!

- Added optional 'stopOn' argument to ZeroOrMore and OneOrMore, to
  simplify breaking on stop tokens that would match the repetition
  expression.

  It is a common problem to fail to look ahead when matching repetitive
  tokens if the sentinel at the end also matches the repetition
  expression, as when parsing "BEGIN aaa bbb ccc END" with:

    "BEGIN" + OneOrMore(Word(alphas)) + "END"

  Since "END" matches the repetition expression \ 
"Word(alphas)", it will
  never get parsed as the terminating sentinel. Up until now, this has
  to be resolved by the user inserting their own negative lookahead:

    "BEGIN" + OneOrMore(~Literal("END") + Word(alphas)) + \ 
"END"

  Using stopOn, they can more easily write:

    "BEGIN" + OneOrMore(Word(alphas), stopOn="END") + \ 
"END"

  The stopOn argument can be a literal string or a pyparsing expression.
  Inspired by a question by Lamakaha on StackOverflow (and many previous
  questions with the same negative-lookahead resolution).

- Added expression names for many internal and builtin expressions, to
  reduce name and error message overhead during parsing.

- Converted helper lambdas to functions to refactor and add docstring
  support.

- Fixed ParseResults.asDict() to correctly convert nested ParseResults
  values to dicts.

- Cleaned up some examples, fixed typo in fourFn.py identified by
  aristotle2600 on reddit.

- Removed keepOriginalText helper method, which was deprecated ages ago.
  Superceded by originalTextFor.

- Same for the Upcase class, which was long ago deprecated and replaced
  with the upcaseTokens method.

Version 2.0.7 - December, 2015
------------------------------
- Simplified string representation of Forward class, to avoid memory
  and performance errors while building ParseException messages. Thanks,
  Will McGugan, Andrea Censi, and Martijn Vermaat for the bug reports and
  test code.

- Cleaned up additional issues from enhancing the error messages for
  Or and MatchFirst, handling Unicode values in expressions. Fixes Unicode
  encoding issues in Python 2, thanks to Evan Hubinger for the bug report.

- Fixed implementation of dir() for ParseResults - was leaving out all the
  defined methods and just adding the custom results names.

- Fixed bug in ignore() that was introduced in pyparsing 1.5.3, that would
  not accept a string literal as the ignore expression.

- Added new example parseTabularData.py to illustrate parsing of data
  formatted in columns, with detection of empty cells.

- Updated a number of examples to more current Python and pyparsing
  forms.

Files:
RevisionActionfile
1.5modifypkgsrc/devel/py-pyparsing/Makefile
1.5modifypkgsrc/devel/py-pyparsing/distinfo