Version 1.3.2

Fixed

• The parser was requesting the next token after an end-statement, even though nothing was done with this token (in the future it could
  be a comment that should be processed). In the very rare case where all of the "data" bytes in a file with an attached PVL label
  (like a .IMG or .cub file) actually convert to UTF with no whitespace characters, that next token will take an unacceptable amount of time to return, if it does at all. The parser now does not request additional tokens once an end-statement is identified (Issue 104).

Version 1.3.1

Fixed

• Deeply nested Aggregation Blocks (Object or Group) which had mis-matched Block Names should now properly result in LexerErrors instead of resulting in StopIteration Exceptions (Issue 100).

• The default "Omni" parsing strategy, now considers the ASCII NULL character ("\0") a "reserved character." The practical effect is that the ASCII NULL can not be in parameter names or unquoted strings (but would still be successfully parsed in quoted strings). This means that PVL-text that might have incorrectly used ASCII NULLs as delimiters will once again be consumed by our omnivorous parser (Issue 98).

Version 1.3.0

Added

• pvl.collections.Quantity objects now have int() and float() functions that will return the int and float versions of their
  .value parameter to facilitate numeric operations with Quantity objects (Issue 91).
• pvl.load() now has an encoding= parameter that is identical in usage to the parameter passed to open(), and will attempt to decode the whole file as if it had been encoded thusly. If it encounters a decoding error, it will fall back to decoding the bytes one at a time as ASCII text (Issue 93).

Fixed

• If the PVL-text contained characters beyond the set allowed by the PVL specification, the OmniGrammar would refuse to parse them.
  This has been fixed to allow any valid character to be parsed, so that if there are weird UTF characters in the PVL-text, you'll get
  those weird UTF characters in the returned dict-like. When the stricter PVL, ODL, or PDS3 dialects are used to "load" PVL-text,
  they will properly fail to parse this text (Issue 93).
• Empty parameters inside groups or objects (but not at the end), would cause the default "Omni" parsing strategy to go into an infinite
  loop. Empty parameters in PVL, ODL, and PDS3 continue to not be allowed (Issue 95).

Bug fixes and test improvements.

Added

• So many tests, increased coverage by about 10%.

Fixed

• Attempting to import pvl.new without multidict being available,
  will now properly yield an ImportError.
• The dump() and dumps() functions now properly overwritten in pvl.new.
• All encoders that descended from PVLEncoder didn't properly have group_class and
  object_class arguments to their constructors, now they do.
• The char_allowed() function in grammar objects now raises a more useful ValueError
  than just a generic Exception.
• The new collections.PVLMultiDict wasn't correctly inserting Mapping objects with
  the insert_before() and insert_after() methods.
• The token.Token class's __index__() function didn't always properly return an
  index.
• The token.Token class's __float__() function would return int objects if the
  token could be converted to int. Now always returns floats.

pvl 1.2.0

v1.2.0

Bump version: 1.2.0-dev → 1.2.0