Navigation Menu

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

Jump to bottom

f-string assert is too restrictive #74867

Closed
ericvsmith opened this issue Jun 16, 2017 · 5 comments
Closed

f-string assert is too restrictive #74867

ericvsmith opened this issue Jun 16, 2017 · 5 comments
Assignees
@ericvsmith
Labels
3.7 (EOL) end of life interpreter-core (Objects, Python, Grammar, and Parser dirs) type-crash A hard crash of the interpreter, possibly with a core dump

Comments

@ericvsmith
Copy link
Member

BPO 30682
Nosy @terryjreedy, @ericvsmith, @ned-deily, @serhiy-storchaka
PRs
  • bpo-30529: Fix assert failure in with pydebug; add tests. #2232
  • [3.6] bpo-30682: Removed a too-strict assertion that failed for certain f-strings. (GH-2232) #2242
    		•

    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/ericvsmith'
closed_at = <Date 2017-06-16.16:49:50.463>
created_at = <Date 2017-06-16.09:13:47.503>
labels = ['interpreter-core', '3.7', 'type-crash']
title = 'f-string assert is too restrictive'
updated_at = <Date 2017-06-16.17:13:05.283>
user = 'https://github.com/ericvsmith'

    bugs.python.org fields:

    activity = <Date 2017-06-16.17:13:05.283>
actor = 'serhiy.storchaka'
assignee = 'eric.smith'
closed = True
closed_date = <Date 2017-06-16.16:49:50.463>
closer = 'eric.smith'
components = ['Interpreter Core']
creation = <Date 2017-06-16.09:13:47.503>
creator = 'eric.smith'
dependencies = []
files = []
hgrepos = []
issue_num = 30682
keywords = []
message_count = 5.0
messages = ['296166', '296174', '296193', '296204', '296212']
nosy_count = 4.0
nosy_names = ['terry.reedy', 'eric.smith', 'ned.deily', 'serhiy.storchaka']
pr_nums = ['2232', '2242']
priority = 'normal'
resolution = 'fixed'
stage = 'resolved'
status = 'closed'
superseder = None
type = 'crash'
url = 'https://bugs.python.org/issue30682'
versions = ['Python 3.6', 'Python 3.7']
    @ericvsmith
    Copy link
    Member Author 

    >>> eval("f'\\\n'")
python: Python/ast.c:4906: FstringParser_ConcatFstring: Assertion `!state->last_str || PyUnicode_GET_LENGTH(state->last_str) != 0' failed.
[2]    12810 abort (core dumped)  ./python

    The problem is that some literal strings are zero length. The assert can be deleted.

    @ericvsmith ericvsmith added the 3.7 (EOL) end of life label Jun 16, 2017
    @ericvsmith ericvsmith self-assigned this Jun 16, 2017
    @ericvsmith ericvsmith added the interpreter-core (Objects, Python, Grammar, and Parser dirs) label Jun 16, 2017
    @serhiy-storchaka
    Copy link
    Member

    New changeset 11e97f2 by Serhiy Storchaka (ericvsmith) in branch 'master':
    bpo-30682: Removed a too-strict assertion that failed for certain f-strings. (bpo-2232)
    11e97f2

    @ericvsmith
    Copy link
    Member Author

    New changeset 2eca5b4 by ericvsmith (Serhiy Storchaka) in branch '3.6':
    [3.6] bpo-30682: Removed a too-strict assertion that failed for certain f-strings. (GH-2232) (bpo-2242)
    2eca5b4

    @terryjreedy
    Copy link
    Member

    Before the patch, eval("f'\\\n'") gives me the same assertion failure, with an IDLE freeze instead of core dump equivalent, but is seems that the string should be of length 2.

    >>> len('\\\n')
2
>>> len(f'\\\n')
2

    @terryjreedy terryjreedy added the type-bug An unexpected behavior, bug, or error label Jun 16, 2017
    @ericvsmith
    Copy link
    Member Author

    Terry:

    The eval is important. The bug was in evaluating an f-string that consisted of two bytes: a backslash followed by a newline.

    And just as:
    eval("'\\\n'") == '' # len == 0
    so should
    eval("f'\\\n'") == '' # len == 0

    It's the second one that was throwing the assertion. The parser was seeing these bytes:
    f 0x66
    ' 0x27
    \ 0x5c
    nl 0xa
    ' 0x27
    and behaving badly (to say the least) by asserting.

    Without the eval, I can't think of a way to have a string consisting of those two bytes, but I assume someone who's trickier than I can come up with a way.

    @serhiy-storchaka serhiy-storchaka added type-crash A hard crash of the interpreter, possibly with a core dump and removed type-bug An unexpected behavior, bug, or error labels Jun 16, 2017
    @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

    @ericvsmith ericvsmith

    Labels
    3.7 (EOL) end of life interpreter-core (Objects, Python, Grammar, and Parser dirs) type-crash A hard crash of the interpreter, possibly with a core dump
    Projects
    None yet
    Milestone
    No milestone
    Development

    No branches or pull requests
    3 participants
    @ericvsmith @serhiy-storchaka @terryjreedy