| msg53139 - (view) |
Author: Amiga Lemming (amigalemming) |
Date: 2001-04-17 12:31 |
| In the re-Module which come with Python version 2.0 (Nov 28 11:10 re.py) the created MatchObjects cannot be copied with a deepcopy(). Switching back to the old "pre.py" as proposed in "re.py" makes everything work ok. |
|
|
| msg53140 - (view) |
Author: Martin v. Löwis (loewis) *  |
Date: 2001-04-26 08:01 |
| Logged In: YES user_id=21627 A patch for that problem is in http://sourceforge.net/tracker/index.php?func=detail&aid=419070&group_id=5470&atid=305470 |
|
|
| msg53141 - (view) |
Author: Fredrik Lundh (effbot) * |
Date: 2001-04-26 21:50 |
| Logged In: YES user_id=38376 I'm not sure this is a bug -- imo, you're relying on an implementation artifact in the original PCRE port. And making this work under SRE isn't as easy as it may appear (the proposed patch may work in your specific case, but it isn't a general solution). But before I make up my mind here, maybe you could tell me why you think it's a good idea to use deepcopy on match objects. Why not just store "m.groups()" or "m.regs" instead? Cheers /F |
|
|
| msg53142 - (view) |
Author: Amiga Lemming (amigalemming) |
Date: 2001-04-27 10:03 |
| Logged In: YES user_id=197994 You are right, m.groupdict() and m.groups() are surely the better choice. |
|
|
| msg53143 - (view) |
Author: Fredrik Lundh (effbot) * |
Date: 2001-04-28 08:53 |
| Logged In: YES user_id=38376 On the other hand, it looks like we've found a rather elegant way to solve this. I'll leave this one open (as a feature request). |
|
|
| msg53144 - (view) |
Author: Brett Cannon (brett.cannon) * |
Date: 2003-05-12 23:14 |
| Logged In: YES user_id=357491 The patch by Martin referenced below was closed since, as Fredrik pointed out in the patch, that re objects have __copy__ and __deepcopy__ methods. Problem is that they are untested so they are basically no-ops after compilation by raising exceptions. So if this feature is still desired someone just needs to work the kinks out of what Fredrik has started. |
|
|
| msg63635 - (view) |
Author: Alexander Belopolsky (belopolsky) * |
Date: 2008-03-17 13:11 |
| A related was closed with no resolution (or resolution did not survive the trip from SF), but it looks like the patch was rejected. Some work towards this issue was done in r21437, but 7 years later it is still marked as work in progress. Is there still interest is this feature? |
|
|
| msg63642 - (view) |
Author: Amiga Lemming (amigalemming) |
Date: 2008-03-17 13:43 |
| On Mon, 17 Mar 2008, Alexander Belopolsky wrote: > Alexander Belopolsky <belopolsky@users.sourceforge.net> added the comment: > > A related was closed with no resolution (or resolution did > not survive the trip from SF), but it looks like the patch was rejected. > > Some work towards this issue was done in r21437, but 7 years later it is > still marked as work in progress. Is there still interest is this > feature? Not by me since I moved to Haskell. :-) |
|
|
| msg75488 - (view) |
Author: Andrew McNamara (andrewmcnamara) * |
Date: 2008-11-04 01:24 |
| One reason why this issue has been having less impact is that a bug in some versions of the copy.py code meant it was ignoring the __deepcopy__ stubs and using the pickle logic to copy _sre objects - so, if you run the right python version, compiled regular expressions and match objects deepcopy without problems. On the 2.4 branch (release24-maint), changeset 38430 introduced the bug that prevents the class __deepcopy__ exception-raising stubs being found. As an aside, I don't understand why the _sre objects should be pickleable, but not deepcopy-able. |
|
|
| msg77516 - (view) |
Author: Martin v. Löwis (loewis) * |
Date: 2008-12-10 09:04 |
| As far as I can tell, there is no proposed patch. So this is out of scope for 2.5.3. |
|
|
| msg113202 - (view) |
Author: Terry J. Reedy (terry.reedy) * |
Date: 2010-08-07 20:57 |
| The OP has no interest in this, there is no patch, and re2 is coming. Should we close this? |
|
|
| msg116560 - (view) |
Author: Mark Lawrence (BreamoreBoy) * |
Date: 2010-09-16 15:17 |
| No reply to . |
|
|