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

string formatting quirk using %.% #47766

Closed
blopblopy mannequin opened this issue Aug 7, 2008 · 4 comments
Closed

string formatting quirk using %.% #47766

blopblopy mannequin opened this issue Aug 7, 2008 · 4 comments
Labels
interpreter-core (Objects, Python, Grammar, and Parser dirs) type-bug An unexpected behavior, bug, or error

Comments

@blopblopy
Copy link
Mannequin

blopblopy mannequin commented Aug 7, 2008

BPO 3516
Nosy @gvanrossum, @birkenfeld, @blopblopy
Files
  • unnamed
  • 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 = None
    closed_at = <Date 2008-08-07.16:51:14.834>
    created_at = <Date 2008-08-07.13:33:04.974>
    labels = ['interpreter-core', 'type-bug']
    title = 'string formatting quirk using %.%'
    updated_at = <Date 2008-08-07.18:01:12.386>
    user = 'https://github.com/blopblopy'

    bugs.python.org fields:

    activity = <Date 2008-08-07.18:01:12.386>
    actor = 'georg.brandl'
    assignee = 'none'
    closed = True
    closed_date = <Date 2008-08-07.16:51:14.834>
    closer = 'gvanrossum'
    components = ['Interpreter Core']
    creation = <Date 2008-08-07.13:33:04.974>
    creator = 'blop'
    dependencies = []
    files = ['11071']
    hgrepos = []
    issue_num = 3516
    keywords = []
    message_count = 4.0
    messages = ['70822', '70838', '70841', '70845']
    nosy_count = 3.0
    nosy_names = ['gvanrossum', 'georg.brandl', 'blop']
    pr_nums = []
    priority = 'normal'
    resolution = 'rejected'
    stage = None
    status = 'closed'
    superseder = None
    type = 'behavior'
    url = 'https://bugs.python.org/issue3516'
    versions = []

    @blopblopy
    Copy link
    Mannequin Author

    blopblopy mannequin commented Aug 7, 2008

    >>> "%.%s" % ()
    '%s'
    >>> "%(a).%(b)s" % dict(a=2)
    '%(b)s'
    >>> "%(a).%(b)s" % dict(a=2, b=3)
    '%(b)s'
    >>> "%(a).%(b)s" % dict()
    Traceback (most recent call last):
      File "<pyshell#6>", line 1, in -toplevel-
        "%(a).%(b)s" % dict()
    KeyError: 'a'

    this is counter intuitive and cannot be deduced from the documentation.

    @blopblopy blopblopy mannequin added interpreter-core (Objects, Python, Grammar, and Parser dirs) type-bug An unexpected behavior, bug, or error labels Aug 7, 2008
    @gvanrossum
    Copy link
    Member

    It's straightforward if you consider the implementation of the
    requirement that %% renders a single percent sign: the second % is
    parsed just like any other formatting code (i, d, f, etc.) and the stuff
    between the first % and the formatting code is treated completely uniformly.

    @blopblopy
    Copy link
    Mannequin Author

    blopblopy mannequin commented Aug 7, 2008

    The main problem with this is that the following code does not make any
    sense:
    "%(a)%" % dict(a=3)

    It has no semantic meaning (take the dictionary paramater a, and do nothing
    with it).
    It must be a user bug (except in very wierd cases).

    I agree that when I consider the implementaion, it makes sense, but as a
    python user, this behavior is really non-intuitive.

    2008/8/7 Guido van Rossum <report@bugs.python.org>

    Guido van Rossum <guido@python.org> added the comment:

    It's straightforward if you consider the implementation of the
    requirement that %% renders a single percent sign: the second % is
    parsed just like any other formatting code (i, d, f, etc.) and the stuff
    between the first % and the formatting code is treated completely
    uniformly.

    ----------
    nosy: +gvanrossum
    resolution: -> rejected
    status: open -> closed


    Python tracker <report@bugs.python.org>
    <http://bugs.python.org/issue3516\>


    @birkenfeld
    Copy link
    Member

    I'd rather see it this way: It is a programming error if a format string
    contains a reference to a nonexisting dictionary key, no matter what
    formatting specifier is used. The implementation is quite consistent here.

    @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
    Labels
    interpreter-core (Objects, Python, Grammar, and Parser dirs) type-bug An unexpected behavior, bug, or error
    Projects
    None yet
    Development

    No branches or pull requests

    2 participants