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.

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

Jump to bottom

pygettext doesn't work with f-strings #77370

Closed
RiccardoPolignieri mannequin opened this issue Mar 30, 2018 · 8 comments
Closed

pygettext doesn't work with f-strings #77370

RiccardoPolignieri mannequin opened this issue Mar 30, 2018 · 8 comments
Assignees
@serhiy-storchaka
Labels
3.7 (EOL) end of life 3.8 only security fixes type-bug An unexpected behavior, bug, or error

Comments

@RiccardoPolignieri
Copy link
Mannequin

RiccardoPolignieri mannequin commented Mar 30, 2018

BPO 33189
Nosy @malemburg, @scoder, @ericvsmith, @merwok, @serhiy-storchaka, @miss-islington
PRs
  • bpo-33189: pygettext.py now accepts only literal strings #6364
  • [3.7] bpo-33189: pygettext.py now accepts only literal strings (GH-6364) #6533
  • [3.6] bpo-33189: pygettext.py now accepts only literal strings (GH-6364) #6534
  • [3.6] bpo-33189: pygettext.py now accepts only literal strings (GH-6364) #6535
    		•

    Note: these values reflect the state of the issue at the time it was migrated and might not reflect the current state.

    Show more details

    GitHub fields:

    assignee = 'https://github.com/serhiy-storchaka'
closed_at = <Date 2018-04-19.07:48:45.584>
created_at = <Date 2018-03-30.20:25:16.363>
labels = ['3.8', 'type-bug', '3.7']
title = "pygettext doesn't work with f-strings"
updated_at = <Date 2018-04-19.07:48:45.584>
user = 'https://bugs.python.org/RiccardoPolignieri'

    bugs.python.org fields:

    activity = <Date 2018-04-19.07:48:45.584>
actor = 'serhiy.storchaka'
assignee = 'serhiy.storchaka'
closed = True
closed_date = <Date 2018-04-19.07:48:45.584>
closer = 'serhiy.storchaka'
components = ['Demos and Tools']
creation = <Date 2018-03-30.20:25:16.363>
creator = 'Riccardo Polignieri'
dependencies = []
files = []
hgrepos = []
issue_num = 33189
keywords = ['patch']
message_count = 8.0
messages = ['314712', '314776', '314780', '314878', '315389', '315481', '315482', '315483']
nosy_count = 7.0
nosy_names = ['lemburg', 'scoder', 'eric.smith', 'eric.araujo', 'serhiy.storchaka', 'miss-islington', 'Riccardo Polignieri']
pr_nums = ['6364', '6533', '6534', '6535']
priority = 'normal'
resolution = 'fixed'
stage = 'resolved'
status = 'closed'
superseder = None
type = 'behavior'
url = 'https://bugs.python.org/issue33189'
versions = ['Python 3.6', 'Python 3.7', 'Python 3.8']
    @RiccardoPolignieri
    Copy link
    Mannequin Author

    RiccardoPolignieri mannequin commented Mar 30, 2018

    Tested (on windows) with python 3.6, but I guess it's the same in py3.7:

    # test.py
def hello(x):
  print(_(f'hello {x}'))
    > py pygettext.py test.py
Traceback (most recent call last):
  File "C:\Program Files\Python36\Tools\i18n\pygettext.py", line 623, in <module>
    if __name__ == '__main__':
  File "C:\Program Files\Python36\Tools\i18n\pygettext.py", line 597, in main
    for _token in tokens:
  File "C:\Program Files\Python36\Tools\i18n\pygettext.py", line 328, in __call__
    ##              'tstring:', tstring
  File "C:\Program Files\Python36\Tools\i18n\pygettext.py", line 382, in __openseen
    elif ttype == tokenize.STRING:
  File "C:\Program Files\Python36\Tools\i18n\pygettext.py", line 236, in safe_eval
    # unwrap quotes, safely
  File "<string>", line 1, in <module>
NameError: name 'x' is not defined

    @RiccardoPolignieri RiccardoPolignieri mannequin added 3.7 (EOL) end of life type-bug An unexpected behavior, bug, or error labels Mar 30, 2018
    @scoder
    Copy link
    Contributor

    scoder commented Apr 1, 2018

    Is there really a use case for this?

    I would normally expect place holders to get replaced *after* translation, i.e. in the translated text, not before.

    @serhiy-storchaka
    Copy link
    Member

    I agree that pygettext should not and can not support f-strings, but the error should be better. The problem is that an f-string expression is tokenized as literal strings, but eval() can't evaluate it out of context.

    @serhiy-storchaka serhiy-storchaka added the 3.8 only security fixes label Apr 1, 2018
    @RiccardoPolignieri
    Copy link
    Mannequin Author

    RiccardoPolignieri mannequin commented Apr 3, 2018

    the error should be better

    Yes, that's what I maeant - sorry I should have phrased better.
    I marked by mistake a couple of f-strings for translation and totally forgot about it for a while... it took me some time to figure out what was going on with this NameError popping out of nowhere.

    Curiously, xgettext handles this thing better (...or, far worse actually): it just parses the f-string as a regular one, producing something like
    msgid "hello {x}"
    msgstr ""
    But then of course Python will fail *silently* at runtime, never picking up the translated version of the string...

    @serhiy-storchaka
    Copy link
    Member

    If there are no objections I'm going to merge PR 6364 in 24 hours.

    @serhiy-storchaka serhiy-storchaka self-assigned this Apr 17, 2018
    @serhiy-storchaka
    Copy link
    Member

    New changeset 6952482 by Serhiy Storchaka in branch 'master':
    bpo-33189: pygettext.py now accepts only literal strings (GH-6364)
    6952482

    @miss-islington
    Copy link
    Contributor

    New changeset a4fb580 by Miss Islington (bot) in branch '3.7':
    bpo-33189: pygettext.py now accepts only literal strings (GH-6364)
    a4fb580

    @miss-islington
    Copy link
    Contributor

    New changeset 6f87093 by Miss Islington (bot) in branch '3.6':
    bpo-33189: pygettext.py now accepts only literal strings (GH-6364)
    6f87093

    @ezio-melotti ezio-melotti transferred this issue from another repository Apr 10, 2022
    Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
    Assignees

    @serhiy-storchaka serhiy-storchaka

    Labels
    3.7 (EOL) end of life 3.8 only security fixes type-bug An unexpected behavior, bug, or error
    Projects
    None yet
    Milestone
    No milestone
    Development

    No branches or pull requests
    3 participants
    @scoder @serhiy-storchaka @miss-islington