Next | Query returned 23 messages, browsing 1 to 10 | Previous

History of commit frequency

CVS Commit History:

   2020-04-07 14:08:13 by Adam Ciarcinski | Files touched by this commit (2) | Package updated
Log message:
py-pyparsing: updated to 2.4.7

Version 2.4.7
- Backport of selected fixes from 3.0.0 work:
  . Each bug with Regex expressions
  . And expressions not properly constructing with generator
  . Traceback abbreviation
  . Bug in delta_time example
  . Fix regexen in pyparsing_common.real and .sci_real
  . Avoid FutureWarning on Python 3.7 or later
  . Cleanup output in runTests if comments are embedded in test string
   2020-01-03 13:47:22 by Adam Ciarcinski | Files touched by this commit (2) | Package updated
Log message:
py-pyparsing: updated to 2.4.6

Version 2.4.6:

- Fixed typos in White mapping of whitespace characters, to use
  correct "\u" prefix instead of "u\".

- Fix bug in left-associative ternary operators defined using
  infixNotation. First reported on StackOverflow by user Jeronimo.

- Backport of pyparsing_test namespace from 3.0.0, including
  TestParseResultsAsserts mixin class defining unittest-helper
  . def assertParseResultsEquals(
            self, result, expected_list=None, expected_dict=None, msg=None)
  . def assertParseAndCheckList(
            self, expr, test_string, expected_list, msg=None, verbose=True)
  . def assertParseAndCheckDict(
            self, expr, test_string, expected_dict, msg=None, verbose=True)
  . def assertRunTestResults(
            self, run_tests_report, expected_parse_results=None, msg=None)
  . def assertRaisesParseException(self, exc_type=ParseException, msg=None)

  To use the methods in this mixin class, declare your unittest classes as:

    from pyparsing import pyparsing_test as ppt
    class MyParserTest(ppt.TestParseResultsAsserts, unittest.TestCase):
   2019-11-11 16:14:30 by Thomas Klausner | Files touched by this commit (1)
Log message:
py-pyparsing: remove removed patch from distinfo
   2019-11-11 16:12:52 by Adam Ciarcinski | Files touched by this commit (3) | Package updated
Log message:
py-pyparsing: updated to 2.4.5

Version 2.4.5:
- Fixed encoding when reads README.rst to include the
  project long description when uploading to PyPI. A stray
  unicode space in README.rst prevented the source install on
  systems whose default encoding is not 'utf-8'.
   2019-11-08 10:47:55 by Thomas Klausner | Files touched by this commit (2)
Log message:
py-pyparsing: fix build with python 3.6
   2019-11-06 10:31:29 by Adam Ciarcinski | Files touched by this commit (2) | Package updated
Log message:
py-pyparsing: updated to 2.4.4

Version 2.4.4:
- Unresolved symbol reference in 2.4.3 release was masked by stdout
  buffering in unit tests.

Version 2.4.3:
- Fixed a bug in ParserElement.__eq__ that would for some parsers
  create a recursion error at parser definition time.
- Fixed bug in indentedBlock where a block that ended at the end
  of the input string could cause pyaprsing to loop forever.
- Backports from pyparsing 3.0.0:
  . __diag__.enable_all_warnings()
  . Fixed bug in PrecededBy which caused infinite recursion
  . support for using regex-compiled RE to construct Regex expressions
   2019-08-21 15:03:41 by Adam Ciarcinski | Files touched by this commit (2) | Package updated
Log message:
py-pyparsing: updated to 2.4.2

Version 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:
     - expr[...] and expr[0, ...] are equivalent to ZeroOrMore(expr)
     - expr[1, ...] is equivalent to OneOrMore(expr)
     - expr[n, ...] or expr[n,] is equivalent
          to expr*n + ZeroOrMore(expr)
          (read as "n or more instances of expr")
     - expr[..., n] is equivalent to expr*(0, n)
     - expr[m, n] is equivalent to expr*(m, n)
  Note that expr[..., n] and expr[m, n] do not raise an exception
  if more than n exprs exist in the input stream.  If this
  behavior is desired, then write expr[..., n] + ~expr.

  Better interpretation of [...] as ZeroOrMore raised by crowsonkb,
  thanks for keeping me in line!

  If upgrading from 2.4.1 or and you have used `expr[...]`
  for `OneOrMore(expr)`, it must be updated to `expr[1, ...]`.

- 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.

      import pyparsing as pp
      pp.__diag__.warn_multiple_tokens_in_named_alternation = True

- 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!
   2019-04-08 12:41:05 by Adam Ciarcinski | Files touched by this commit (2) | Package updated
Log message:
py-pyparsing: updated to 2.4.0

Version 2.4.0:

- Well, it looks like the API change that was introduced in 2.3.1 was more
  drastic than expected, so for a friendlier forward upgrade path, this
  . Bumps the current version number to 2.4.0, to reflect this
    incompatible change.
  . Adds a pyparsing.__compat__ object for specifying compatibility with
    future breaking changes.
  . Conditionalizes the API-breaking behavior, based on the value
    pyparsing.__compat__.collect_all_And_tokens.  By default, this value
    will be set to True, reflecting the new bugfixed behavior. To set this
    value to False, add to your code:

        import pyparsing
        pyparsing.__compat__.collect_all_And_tokens = False

  . User code that is dependent on the pre-bugfix behavior can restore
    it by setting this value to False.

  In 2.5 and later versions, the conditional code will be removed and
  setting the flag to True or False in these later versions will have no

- Updated and to be compatible with
  "python test". To run tests using setup, do:

      python test
      python test -s unitTests.suite
      python test -s simple_unit_tests.suite

- Fixed bug in runTests handling '\n' literals in quoted strings.

- Added tag_body attribute to the start tag expressions generated by
  makeHTMLTags, so that you can avoid using SkipTo to roll your own
  tag body expression:

      a, aEnd = pp.makeHTMLTags('a')
      link = a + a.tag_body("displayed_text") + aEnd
      for t in s.searchString(html_page):
          print(t.displayed_text, '->', t.startA.href)

- indentedBlock failure handling was improved

- Address Py2 incompatibility in simpleUnitTests, plus explain() and
  Forward str() cleanup.

- Fixed docstring with embedded '\w', which creates SyntaxWarnings in

- Examples:
  - Added example parser for tutorial compiler.

  - Added example to show how an HTML table can be parsed into a
    collection of Python lists or dicts, one per row.

  - Updated example to handle nested selects, reworked
    'where' expression to use infixNotation.

  - Added, similar to

  - Examples using makeHTMLTags use new tag_body expression when
    retrieving a tag's body text.

  - Updated examples that are runnable as unit tests:
        python test -s examples.antlr_grammar_tests
        python test -s examples.test_bibparse
   2019-01-15 12:37:21 by Adam Ciarcinski | Files touched by this commit (2) | Package updated
Log message:
py-pyparsing: updated to 2.3.1

Version 2.3.1
- POSSIBLE API CHANGE: this release fixes a bug when results names were
  attached to a MatchFirst or Or object containing an And object.
  Previously, a results name on an And object within an enclosing MatchFirst
  or Or could return just the first token in the And. Now, all the tokens
  matched by the And are correctly returned. This may result in subtle
  changes in the tokens returned if you have this condition in your pyparsing

- New staticmethod ParseException.explain() to help diagnose parse exceptions
  by showing the failing input line and the trace of ParserElements in
  the parser leading up to the exception. explain() returns a multiline
  string listing each element by name. (This is still an experimental
  method, and the method signature and format of the returned string may
  evolve over the next few releases.)

        # define a parser to parse an integer followed by an
        # alphabetic word
        expr = pp.Word(pp.nums).setName("int")
               + pp.Word(pp.alphas).setName("word")
            # parse a string with a numeric second value instead of alpha
            expr.parseString("123 355")
        except pp.ParseException as pe:

        123 355
        ParseException: Expected word (at char 4), (line:1, col:5)
        pyparsing.And - {int word}
        pyparsing.Word - word

  explain() will accept any exception type and will list the function
  names and parse expressions in the stack trace. This is especially
  useful when an exception is raised in a parse action.

  Note: explain() is only supported under Python 3.

- Fix bug in dictOf which could match an empty sequence, making it
  infinitely loop if wrapped in a OneOrMore.

- Added unicode sets to pyparsing_unicode for Latin-A and Latin-B ranges.

- Added ability to define custom unicode sets as combinations of other sets
  using multiple inheritance.

    class Turkish_set(pp.pyparsing_unicode.Latin1, pp.pyparsing_unicode.LatinA):

    turkish_word = pp.Word(Turkish_set.alphas)

- Updated state machine import examples, with state machine demos for:
  . traffic light
  . library book checkin/checkout
  . document review/approval

  In the traffic light example, you can use the custom 'statemachine' keyword
  to define the states for a traffic light, and have the state classes
  auto-generated for you:

      statemachine TrafficLightState:
          Red -> Green
          Green -> Yellow
          Yellow -> Red

  Similar for state machines with named transitions, like the library book
  state example:

      statemachine LibraryBookState:
          New -(shelve)-> Available
          Available -(reserve)-> OnHold
          OnHold -(release)-> Available
          Available -(checkout)-> CheckedOut
          CheckedOut -(checkin)-> Available

  Once the classes are defined, then additional Python code can reference those
  classes to add class attributes, instance methods, etc.

  See the examples in examples/statemachine

- Added an example parser for the decaf language. This language is used in
  CS compiler classes in many colleges and universities.

- Fixup of docstrings to Sphinx format, inclusion of test files in the source
  package, and convert markdown to rst throughout the distribution, great job
  by Matěj Cepl!

- Expanded the whitespace characters recognized by the White class to include
  all unicode defined spaces.

- Added optional postParse argument to ParserElement.runTests() to add a
  custom callback to be called for test strings that parse successfully. Useful
  for running tests that do additional validation or processing on the parsed
  results. See updated example.

- Removed distutils fallback in If installing the package fails,
  please update to the latest version of setuptools. Plus overall project code
  cleanup (CRLFs, whitespace, imports, etc.), thanks Jon Dufresne!

- Fix bug in CaselessKeyword, to make its behavior consistent with
   2018-12-10 16:18:41 by Adam Ciarcinski | Files touched by this commit (2) | Package updated
Log message:
py-pyparsing: 2.3.0

Version 2.3.0:
  This release introduces the pyparsing_unicode namespace class, defining
  a series of language character sets to simplify the definition of alphas,
  nums, alphanums, and printables in the following language sets:
   . Arabic
   . Chinese
   . Cyrillic
   . Devanagari
   . Greek
   . Hebrew
   . Japanese (including Kanji, Katakana, and Hirigana subsets)
   . Korean
   . Latin1 (includes 7 and 8-bit Latin characters)
   . Thai
   . CJK (combination of Chinese, Japanese, and Korean sets)

  For example, your code can define words using:

    korean_word = Word(pyparsing_unicode.Korean.alphas)

  See their use in the updated examples and

  This namespace class also offers access to these sets using their
  unicode identifiers.

- POSSIBLE API CHANGE: Fixed bug where a parse action that explicitly
  returned the input ParseResults could add another nesting level in
  the results if the current expression had a results name.

        vals = pp.OneOrMore(pp.pyparsing_common.integer)("int_values")

        def add_total(tokens):
            tokens['total'] = sum(tokens)
            return tokens  # this line can be removed

        print(vals.parseString("244 23 13 2343").dump())

  Before the fix, this code would print (note the extra nesting level):

    [244, 23, 13, 2343]
    - int_values: [244, 23, 13, 2343]
      - int_values: [244, 23, 13, 2343]
      - total: 2623
    - total: 2623

  With the fix, this code now prints:

    [244, 23, 13, 2343]
    - int_values: [244, 23, 13, 2343]
    - total: 2623

  This fix will change the structure of ParseResults returned if a
  program defines a parse action that returns the tokens that were
  sent in. This is not necessary, and statements like "return tokens"
  in the example above can be safely deleted prior to upgrading to
  this release, in order to avoid the bug and get the new behavior.

  Reported by seron in Issue 22, nice catch!

- POSSIBLE API CHANGE: Fixed a related bug where a results name
  erroneously created a second level of hierarchy in the returned
  ParseResults. The intent for accumulating results names into ParseResults
  is that, in the absence of Group'ing, all names get merged into a
  common namespace. This allows us to write:

       key_value_expr = (Word(alphas)("key") + '=' + \ 
       result = key_value_expr.parseString("a = 100")

  and have result structured as {"key": "a", \ 
"value": "100"}
  instead of [{"key": "a"}, {"value": \ 

  However, if a named expression is used in a higher-level non-Group
  expression that *also* has a name, a false sub-level would be created
  in the namespace:

        num = pp.Word(pp.nums)
        num_pair = ("[" + (num("A") + \ 
num("B"))("values") + "]")
        U = num_pair.parseString("[ 10 20 ]")

  Since there is no grouping, "A", "B", and \ 
"values" should all appear
  at the same level in the results, as:

        ['[', '10', '20', ']']
        - A: '10'
        - B: '20'
        - values: ['10', '20']

  Instead, an extra level of "A" and "B" show up under \ 

        ['[', '10', '20', ']']
        - A: '10'
        - B: '20'
        - values: ['10', '20']
          - A: '10'
          - B: '20'

  This bug has been fixed. Now, if this hierarchy is desired, then a
  Group should be added:

        num_pair = ("[" + pp.Group(num("A") + \ 
num("B"))("values") + "]")


        ['[', ['10', '20'], ']']
        - values: ['10', '20']
          - A: '10'
          - B: '20'

  But in no case should "A" and "B" appear in multiple \ 
levels. This bug-fix
  fixes that.

  If you have current code which relies on this behavior, then add or remove
  Groups as necessary to get your intended results structure.

  Reported by Athanasios Anastasiou.

- IndexError's raised in parse actions will get explicitly reraised
  as ParseExceptions that wrap the original IndexError. Since
  IndexError sometimes occurs as part of pyparsing's normal parsing
  logic, IndexErrors that are raised during a parse action may have
  gotten silently reinterpreted as parsing errors. To retain the
  information from the IndexError, these exceptions will now be
  raised as ParseExceptions that reference the original IndexError.
  This wrapping will only be visible when run under Python3, since it
  emulates "raise ... from ..." syntax.

  Addresses Issue 4, reported by guswns0528.

- Added Char class to simplify defining expressions of a single
  character. (Char("abc") is equivalent to Word("abc", exact=1))

- Added class PrecededBy to perform lookbehind tests. PrecededBy is
  used in the same way as FollowedBy, passing in an expression that
  must occur just prior to the current parse location.

  For fixed-length expressions like a Literal, Keyword, Char, or a
  Word with an `exact` or `maxLen` length given, `PrecededBy(expr)`
  is sufficient. For varying length expressions like a Word with no
  given maximum length, `PrecededBy` must be constructed with an
  integer `retreat` argument, as in
  `PrecededBy(Word(alphas, nums), retreat=10)`, to specify the maximum
  number of characters pyparsing must look backward to make a match.
  pyparsing will check all the values from 1 up to retreat characters
  back from the current parse location.

  When stepping backwards through the input string, PrecededBy does
  *not* skip over whitespace.

  PrecededBy can be created with a results name so that, even though
  it always returns an empty parse result, the result *can* include
  named results.

  Idea first suggested in Issue 30 by Freakwill.

- Updated FollowedBy to accept expressions that contain named results,
  so that results names defined in the lookahead expression will be
  returned, even though FollowedBy always returns an empty list.
  Inspired by the same feature implemented in PrecededBy.

Next | Query returned 23 messages, browsing 1 to 10 | Previous