Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

unorderable types in write_po #606

Closed
mfrasca opened this issue Oct 17, 2018 · 3 comments · Fixed by #646
Closed

unorderable types in write_po #606

mfrasca opened this issue Oct 17, 2018 · 3 comments · Fixed by #646
Assignees
Labels

Comments

@mfrasca
Copy link
Contributor

@mfrasca mfrasca commented Oct 17, 2018

I'm using babel-2.6.0, and I'm hitting a problem with generated data, not something I can fix on that end.

I have a standard Makefile for generating pot files, then I use msgcat to produce a single merged pot, which I then update with the line:

sphinx-intl update -p _build/locale-merged $(for i in $LANGUAGES; do printf -- '-l %s ' $i; done)

and the result is a crash:

babel/messages/pofile.py", line 552, in write_po
    for filename, lineno in sorted(message.locations):
TypeError: unorderable types: NoneType() < int()

which I fixed very brutally by adding a key parameter to the sorted function:

sorted(message.locations, key=(lambda x: (x[0], x[1] or -1)))
@Timtam
Copy link

@Timtam Timtam commented Dec 21, 2018

Same here, when feeding a catalog via

cat.add(
    "some translatable string",
    locations=("/some/path/to/some/file", 20),
    # ...
)

write_po() will always fail due to the attempt of sorting strings and integers in one go.
Will probably have to find an older version which doesn't run into this issue now until you get it fixed.
Best Regards.
Timtam

@akx akx added the bug label Mar 1, 2019
@akx akx self-assigned this May 27, 2019
akx added a commit to akx/babel that referenced this issue May 27, 2019
@akx akx closed this as completed in #646 May 27, 2019
@mfrasca
Copy link
Contributor Author

@mfrasca mfrasca commented May 27, 2019

I'm curious: why the try-except block (giving up on any ordering) instead of a partial ordering function as the approach in my report?

@akx
Copy link
Member

@akx akx commented May 27, 2019

@mfrasca My reasoning was that it could also fail, but come to think of it, I could have made the try:except:'d sorted statement use that key function. If you feel like making a PR for it, we can ship it in 2.7.1 or something :)

mfrasca pushed a commit to mfrasca/babel that referenced this issue May 27, 2019
see issue python-babel#606.  if one object has anything that doesn't compare to `int`, bring it to the top, and correctly sort the rest.
akx pushed a commit that referenced this issue May 28, 2019
see issue #606.  if one object has anything that doesn't compare to `int`, bring it to the top, and correctly sort the rest.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants