Skip to content

deepcopy can't handle custom metaclasses #36650

Closed

Description

@glchapman
mannequin
BPO 560794
Nosy @gvanrossum
Files
  • copy.py.diff
  • copy.py.diff
  • 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/gvanrossum'
    closed_at = <Date 2002-06-10.21:10:39.000>
    created_at = <Date 2002-05-26.19:15:21.000>
    labels = ['library']
    title = "deepcopy can't handle custom metaclasses"
    updated_at = <Date 2002-06-10.21:10:39.000>
    user = 'https://bugs.python.org/glchapman'

    bugs.python.org fields:

    activity = <Date 2002-06-10.21:10:39.000>
    actor = 'gvanrossum'
    assignee = 'gvanrossum'
    closed = True
    closed_date = None
    closer = None
    components = ['Library (Lib)']
    creation = <Date 2002-05-26.19:15:21.000>
    creator = 'glchapman'
    dependencies = []
    files = ['494', '495']
    hgrepos = []
    issue_num = 560794
    keywords = []
    message_count = 3.0
    messages = ['10933', '10934', '10935']
    nosy_count = 2.0
    nosy_names = ['gvanrossum', 'glchapman']
    pr_nums = []
    priority = 'normal'
    resolution = 'accepted'
    stage = None
    status = 'closed'
    superseder = None
    type = None
    url = 'https://bugs.python.org/issue560794'
    versions = ['Python 2.2']

    Activity

    1. glchapman commented on May 26, 2002

      glchapmanmannequin
      MannequinAuthor

      This is essentially the same problem as that reported in
      bug 494904 for pickle: deepcopy should treat instances
      of custom metaclasses the same way it treats
      instances of type 'type'. I've attached a provisional fix
      which is basically a copy of the patch made to pickle (it
      checks to see if the type of the thing being deepcopied
      is a subclass of type).

      One question: it seems to me that the exception
      handling code is unnecessary both here and in the
      pickle module. In both cases, the first parameter to
      subclass is the result of a call to 'type' and the second
      is type 'type' itself, so it doesn't seem like there's any
      reason to worry about a TypeError.

    2. added
      stdlibStandard Library Python modules in the Lib/ directory
      on May 26, 2002
    3. added
      stdlibStandard Library Python modules in the Lib/ directory
      on May 26, 2002
    4. glchapman commented on May 26, 2002

      glchapmanmannequin
      MannequinAuthor

      Logged In: YES
      user_id=86307

      I changed the patch so that issubclass is called before the
      attempt to access __deepcopy__ (to avoid unbound instance
      method problem methioned in 494904).

    5. gvanrossum commented on Jun 10, 2002

      @gvanrossum
      Member

      Logged In: YES
      user_id=6380

      Thanks; I've checked this in. For the reason of the except
      clause, see python.org/sf/502085.

    6. transferred this issue fromon Apr 9, 2022
    Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

    Metadata

    Metadata

    Assignees

    Labels

    stdlibStandard Library Python modules in the Lib/ directory

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions