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

Regex objects became uncopyable in 2.5 #54285

Closed
MichaelShields mannequin opened this issue Oct 12, 2010 · 8 comments
Closed

Regex objects became uncopyable in 2.5 #54285

MichaelShields mannequin opened this issue Oct 12, 2010 · 8 comments
Labels
3.7 (EOL) end of life stdlib Python modules in the Lib dir topic-regex type-feature A feature request or enhancement

Comments

@MichaelShields
Copy link
Mannequin

MichaelShields mannequin commented Oct 12, 2010

BPO 10076
Nosy @orsenthil, @pitrou, @ezio-melotti, @serhiy-storchaka
PRs
  • bpo-10076: Compiled regular expression and match objects now are copy… #1000
  • Superseder
  • bpo-416670: MatchObjects not deepcopy()able
  • Files
  • copy-pattern.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 = None
    closed_at = <Date 2017-04-16.07:17:05.000>
    created_at = <Date 2010-10-12.20:45:22.779>
    labels = ['expert-regex', 'type-feature', 'library', '3.7']
    title = 'Regex objects became uncopyable in 2.5'
    updated_at = <Date 2017-04-16.07:17:04.999>
    user = 'https://bugs.python.org/MichaelShields'

    bugs.python.org fields:

    activity = <Date 2017-04-16.07:17:04.999>
    actor = 'serhiy.storchaka'
    assignee = 'none'
    closed = True
    closed_date = <Date 2017-04-16.07:17:05.000>
    closer = 'serhiy.storchaka'
    components = ['Library (Lib)', 'Regular Expressions']
    creation = <Date 2010-10-12.20:45:22.779>
    creator = 'Michael.Shields'
    dependencies = []
    files = ['19205']
    hgrepos = []
    issue_num = 10076
    keywords = ['patch']
    message_count = 8.0
    messages = ['118469', '118470', '118741', '168988', '169167', '169214', '291166', '291744']
    nosy_count = 8.0
    nosy_names = ['orsenthil', 'pitrou', 'ezio.melotti', 'mrabarnett', 'shields', 'Michael.Shields', 'serhiy.storchaka', '\xd0\x90\xd0\xbd\xd1\x85\xd0\xb1\xd0\xb0\xd1\x8f\xd1\x80.\xd0\x9b\xd1\x85\xd0\xb0\xd0\xb3\xd0\xb2\xd0\xb0\xd0\xb4\xd0\xbe\xd1\x80\xd0\xb6']
    pr_nums = ['1000']
    priority = 'normal'
    resolution = 'fixed'
    stage = 'resolved'
    status = 'closed'
    superseder = '416670'
    type = 'enhancement'
    url = 'https://bugs.python.org/issue10076'
    versions = ['Python 3.7']

    @MichaelShields
    Copy link
    Mannequin Author

    MichaelShields mannequin commented Oct 12, 2010

    For many years now, the sre module has provided __copy__ and __deepcopy__ modules that raise an exception ("cannot copy this pattern object") by default, with an #ifdef to enable their implementations. Until Python 2.5, these were simply unused. Since then, deepcopying these objects fails, instead of falling back to the default implementation.

    Python 2.4.6 (#1, Nov 23 2009, 03:28:22)
    [GCC 4.2.2] on linux2
    Type "help", "copyright", "credits" or "license" for more information.
    >>> import re
    >>> x = [re.compile('.*')]
    >>> import copy
    >>> copy.deepcopy(x)
    [<_sre.SRE_Pattern object at 0x7f3e9411e168>]
    
    Python 2.6.2 (r262:71600, Jul 24 2009, 17:29:21)
    [GCC 4.2.2] on linux2
    Type "help", "copyright", "credits" or "license" for more information.
    >>> import re
    >>> x = [re.compile('.*')]
    >>> import copy
    >>> copy.deepcopy(x)
    Traceback (most recent call last):
     File "<stdin>", line 1, in <module>
     File "/usr/grte/v1/k8-linux/lib/python2.6/copy.py", line 162, in deepcopy
       y = copier(x, memo)
     File "/usr/grte/v1/k8-linux/lib/python2.6/copy.py", line 228, in _deepcopy_list
       y.append(deepcopy(a, memo))
     File "/usr/grte/v1/k8-linux/lib/python2.6/copy.py", line 173, in deepcopy
       y = copier(memo)
    TypeError: cannot deepcopy this pattern object

    I'll attach a patch against 2.7 to correct this.

    @MichaelShields MichaelShields mannequin added type-bug An unexpected behavior, bug, or error stdlib Python modules in the Lib dir labels Oct 12, 2010
    @MichaelShields
    Copy link
    Mannequin Author

    MichaelShields mannequin commented Oct 12, 2010

    Here's the patch. I updated the test case and release notes also.

    I'm a Google employee, so this patch is covered by whatever usual copyright arrangement we have with the PSF.

    @orsenthil
    Copy link
    Member

    The patch looks reasonable to me.

    I was trying to find out why they got disabled after 2.5, but I don't see any reason. (There was an issue open and it was closed for no reason). So, I think, this should move forward, unless there is any technical objection to the patch.

    @ghost
    Copy link

    ghost commented Aug 24, 2012

    Ding.

    @mrabarnett
    Copy link
    Mannequin

    mrabarnett mannequin commented Aug 26, 2012

    Is it necessary to actually copy it? Isn't the pattern object immutable?

    @shields
    Copy link
    Mannequin

    shields mannequin commented Aug 27, 2012

    It's not strictly necessary that re objects be copyable, but there's no reason to break it either. It's not strictly necessary that str or int be copyable either.

    This came up in code that had objects with a number of members, one of which was a regexp pattern object. deepcopy of this object broke in 2.5.

    @serhiy-storchaka
    Copy link
    Member

    Since the pattern and the match objects can be considered as immutable, it is worth to implement __copy__ and __deepcopy__ returning the object itself. Proposed PR does this. It also fixes signatures of __deepcopy__ methods.

    Since copying didn't work in all maintained version for long time, this is rather a new feature than a bug fix.

    @serhiy-storchaka serhiy-storchaka added 3.7 (EOL) end of life type-feature A feature request or enhancement and removed type-bug An unexpected behavior, bug, or error labels Apr 5, 2017
    @serhiy-storchaka
    Copy link
    Member

    New changeset fdbd011 by Serhiy Storchaka in branch 'master':
    bpo-10076: Compiled regular expression and match objects now are copyable. (bpo-1000)
    fdbd011

    @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.7 (EOL) end of life stdlib Python modules in the Lib dir topic-regex type-feature A feature request or enhancement
    Projects
    None yet
    Development

    No branches or pull requests

    3 participants