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

typing.NamedTuple to switch from OrderedDict to regular dict #80501

Closed
rhettinger opened this issue Mar 16, 2019 · 7 comments
Closed

typing.NamedTuple to switch from OrderedDict to regular dict #80501

rhettinger opened this issue Mar 16, 2019 · 7 comments
Assignees
Labels
3.8 only security fixes stdlib Python modules in the Lib dir type-bug An unexpected behavior, bug, or error

Comments

@rhettinger
Copy link
Contributor

BPO 36320
Nosy @rhettinger, @serhiy-storchaka, @MojoVampire, @ilevkivskyi, @miss-islington
PRs
  • bpo-36320: Switch typing.NamedTuple from OrderedDict to regular dict #12396
  • [3.8] bpo-36320: Use the deprecated-removed directive for _field_types #19370
  • 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/ilevkivskyi'
    closed_at = <Date 2019-03-18.16:56:15.859>
    created_at = <Date 2019-03-16.20:10:01.852>
    labels = ['3.8', 'type-bug', 'library']
    title = 'typing.NamedTuple to switch from OrderedDict to regular dict'
    updated_at = <Date 2020-04-04.21:43:10.562>
    user = 'https://github.com/rhettinger'

    bugs.python.org fields:

    activity = <Date 2020-04-04.21:43:10.562>
    actor = 'serhiy.storchaka'
    assignee = 'levkivskyi'
    closed = True
    closed_date = <Date 2019-03-18.16:56:15.859>
    closer = 'rhettinger'
    components = ['Library (Lib)']
    creation = <Date 2019-03-16.20:10:01.852>
    creator = 'rhettinger'
    dependencies = []
    files = []
    hgrepos = []
    issue_num = 36320
    keywords = ['patch']
    message_count = 7.0
    messages = ['338095', '338130', '338136', '338243', '338253', '338259', '365792']
    nosy_count = 5.0
    nosy_names = ['rhettinger', 'serhiy.storchaka', 'josh.r', 'levkivskyi', 'miss-islington']
    pr_nums = ['12396', '19370']
    priority = 'normal'
    resolution = 'fixed'
    stage = 'resolved'
    status = 'closed'
    superseder = None
    type = 'behavior'
    url = 'https://bugs.python.org/issue36320'
    versions = ['Python 3.8']

    @rhettinger
    Copy link
    Contributor Author

    Suggestions:

    • Deprecate _field_types in favor of __annotations__.
    • Convert __annotations__ from OrderedDict to a regular dict.

    This will make the API cleaner. The first one will also remove a difference between NamedTuple and namedtuple(). The second is consistent with the decision to convert _asdict() to a regular dictionary since OrderedDict is no longer necessary or desirable. The second will also make the signature of __annotations__ match that from other classes.

    @rhettinger rhettinger added the 3.8 only security fixes label Mar 16, 2019
    @rhettinger rhettinger added stdlib Python modules in the Lib dir type-bug An unexpected behavior, bug, or error labels Mar 16, 2019
    @ilevkivskyi
    Copy link
    Member

    Good idea! This should be easy to fix/update, this was initially discussed in python/typing#339.

    @rhettinger
    Copy link
    Contributor Author

    Okay, I'll put together a PR and assign it to you :-)

    @MojoVampire
    Copy link
    Mannequin

    MojoVampire mannequin commented Mar 18, 2019

    Would it make sense to convert _field_types to a property, so the method(s) that implement the property can do:

    warnings.warn("_field_types is deprecated; use __annotations__ instead", DeprecationWarning)

    to indicate the deprecation programmatically, not just in the documentation? The property could be backed by __annotations__ directly; they're already aliases of one another, so the only difference in behavior would be if someone was actually reassigning _field_types after class definition time (which I'm hoping is an invalid use case...). Would save some headaches for folks who run with warnings enabled, but don't read the What's New notices in detail.

    @MojoVampire
    Copy link
    Mannequin

    MojoVampire mannequin commented Mar 18, 2019

    Blech. Just remembered _field_types is a *class* attribute, not an instance attribute, so it (just) can't be a plain property on NamedTuple itself.

    And because NamedTuple is super-weird (AFAICT, class X(typing.NamedTuple): pass defines a class where the class is not a subclass of typing.NamedTuple, nor are its instances instances of NamedTuple, it's just wrapping an invocation of collections.namedtuple, which directly subclasses tuple with no metaclass involvement), and making a "class property" of the type we'd need requires a metaclass (which for tuple subclasses isn't an option), serious hackery or both ( https://stackoverflow.com/q/5189699/364696 ), it's probably not worth the effort to provide this warning. The only way to do it, AFAICT, would be to give the root tuple class a metaclass to provide the _field_types property, and that's a non-starter given it would, among other things, probably slow every single use of tuples just to provide the warning for this one niche case.

    Boo.

    @miss-islington
    Copy link
    Contributor

    New changeset f7b57df by Miss Islington (bot) (Raymond Hettinger) in branch 'master':
    bpo-36320: Switch typing.NamedTuple from OrderedDict to regular dict (GH-12396)
    f7b57df

    @serhiy-storchaka
    Copy link
    Member

    New changeset 0d1d7c8 by Serhiy Storchaka in branch '3.8':
    bpo-36320: Use the deprecated-removed directive for _field_types (GH-19370)
    0d1d7c8

    @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
    3.8 only security fixes stdlib Python modules in the Lib dir type-bug An unexpected behavior, bug, or error
    Projects
    None yet
    Development

    No branches or pull requests

    4 participants