Thanks to visit codestin.com
Credit goes to github.com

Skip to content

gh-130453: pygettext: Extend support for specifying custom keywords #130463

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.

Sign up for GitHub

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

Merged
serhiy-storchaka merged 10 commits into from
Feb 25, 2025
Merged

gh-130453: pygettext: Extend support for specifying custom keywords #130463

Changes from 1 commit
Commits
Show all changes
10 commits
Select commit Hold shift + click to select a range
74b0235
Support custom keywords
tomasr8 Feb 9, 2025
619cad5
Add news entry
tomasr8 Feb 22, 2025
184232e
PEP8
tomasr8 Feb 22, 2025
4dd889b
Remove whitespace
tomasr8 Feb 22, 2025
6a46ce7
Remove trailing whitespace
tomasr8 Feb 22, 2025
bb50cfe
Simplify code
tomasr8 Feb 23, 2025
83a21e0
Revert making keywords a set
tomasr8 Feb 23, 2025
d861c84
Simplify 'parse_spec'
tomasr8 Feb 23, 2025
18d29cb
Use print+sys.exit for consistency
tomasr8 Feb 23, 2025
a3ef55b
Revert changes to parse_spec
tomasr8 Feb 24, 2025
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
Prev Previous commit
Revert changes to parse_spec
  • Loading branch information
@tomasr8
tomasr8 committed Feb 24, 2025
commit a3ef55bc629d77a0a673d94621d77dac61bb07b4
18 changes: 9 additions & 9 deletions Tools/i18n/pygettext.py
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -352,28 +352,28 @@ def parse_spec(spec):
raise ValueError(f'Invalid keyword spec {spec!r}: '
'argument positions must be strictly positive')

if pos in result:
if pos in result.values():
raise ValueError(f'Invalid keyword spec {spec!r}: '
'duplicate positions')

if is_context:
if 'msgctxt' in result.values():
if 'msgctxt' in result:
raise ValueError(f'Invalid keyword spec {spec!r}: '
'msgctxt can only appear once')
result[pos] = 'msgctxt'
elif 'msgid' not in result.values():
result[pos] = 'msgid'
elif 'msgid_plural' not in result.values():
result[pos] = 'msgid_plural'
result['msgctxt'] = pos
elif 'msgid' not in result:
result['msgid'] = pos
elif 'msgid_plural' not in result:
result['msgid_plural'] = pos
else:
raise ValueError(f'Invalid keyword spec {spec!r}: '
'too many positions')

if 'msgid' not in result.values() and 'msgctxt' in result.values():
if 'msgid' not in result and 'msgctxt' in result:
raise ValueError(f'Invalid keyword spec {spec!r}: '
'msgctxt cannot appear without msgid')

return name, result
return name, {v: k for k, v in result.items()}
Copy link
Copy Markdown
Member

@serhiy-storchaka serhiy-storchaka Feb 23, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Would it be simpler to build result in that form from the beginning?

Copy link
Copy Markdown
Member Author

@tomasr8 tomasr8 Feb 23, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I did that in d861c84, let me know if you like it better like that

Copy link
Copy Markdown
Member

@serhiy-storchaka serhiy-storchaka Feb 23, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It was just a question. I am fine with both variants.

Copy link
Copy Markdown
Member Author

@tomasr8 tomasr8 Feb 23, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I just wanted to let you see the difference :) I don't have a strong preference either, let's stick with the current version, then?

Copy link
Copy Markdown
Member Author

@tomasr8 tomasr8 Feb 24, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Actually, I tried implementing some followup work on top of this PR (support for the t specifier, multiple keywords with the same funcname) and it's better to use the original representation because the diff in the followup PRs will be smaller.

Copy link
Copy Markdown
Member

@serhiy-storchaka serhiy-storchaka Feb 25, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

So I did the right thing by letting the PR lie down for two days. 😄

Copy link
Copy Markdown
Member Author

@tomasr8 tomasr8 Feb 25, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes, good call 🙂 And thanks for your super thorough reviews! It's really appreciated



@dataclass(frozen=True)
Expand Down