Issue #36 wontfix

please make detecting header field duplicates feasible

Jakub Wilk
created an issue

I'd like to be able to detect header field duplicates in PO/MO files. For PO files, I can do it by monkey-patching polib code, but this techique doesn't work for the MO parser.

Could you perhaps move the header parser to a separate function? This way you could avoid code duplication, and make it possible to substitue the parser easily with a customized one. Thanks in advance.

Comments (6)

  1. Jakub Wilk reporter

    Here's my first shot at the header parser refactoring:

    Note that the parser is stricter that the original one, which would silently ignore some malformed header parts.

    I let the parse_metadata() function throw ValueError when it cannot parse the header. I feel like exception handling should be improved somehow, but I don't know how to do it sensible. It's because how the original code does exception handling is both inconsisten and not very helpful:

    • As far as I can see, the PO parser will only throw IOError on parse errors, even though they have nothing to do with I/O.
    • The MO parser on the other hand does almost no consistency checking; it lets various exceptions, such as ValueError or struct.error, go through.
  2. David Jean Louis repo owner

    Any progress on this ? Do you think you'll be able to make a pull request ? Feel free to correct what you find inconsistent as long as it does not break BC.

  3. Jakub Wilk reporter

    No, sorry, no progress here. Finishing the work would require a design decision on how errors should be handled within the library. I'm not in a position to make such decision. Also, I don't think it can be done in a backwards-compatible way.

  4. David Jean Louis repo owner

    I think polib should not handle exceptions too much, IMO it's better for a library (not a framework, nor an app) to let original exceptions propagate instead of re-raising home made exceptions. That said I agree that IOError was a bad choice, ValueError would have been more appropriate !

    I'm closing the issue as "wontfix", feel free to re-open it if you wan't to work on it someday.


  5. Log in to comment