> it's probably best to upgrade to the current SRE code base. I'd be concerned about the "pure bugfix" nature of the current SRE code base. It is probably minor things, like the addition of + PyDict_SetItemString( + d, "MAGIC", (PyObject*) PyInt_FromLong(SRE_MAGIC) + ); +# public symbols +__all__ = [ "match", "search", "sub", "subn", "split", "findall", + "compile", "purge", "template", "escape", "I", "L", "M", "S", "X", + "U", "IGNORECASE", "LOCALE", "MULTILINE", "DOTALL", "VERBOSE", + "UNICODE", "error" ] + +DEBUG = sre_compile.SRE_FLAG_DEBUG # dump pattern after compilation - def getgroup(self, name=None): + def opengroup(self, name=None): The famous last words here are "those changes can do no harm". However, somebody might rely on Pattern objects having a getgroup method (even though it is not documented). Some code (relying on undocumented features) may break with 2.1, which is acceptable; it is not acceptable for a bugfix release. For the bugfix release, I'd feel much better if a clear set of pure bug fixes were identified, along with a list of bugs they fix. So "no new feature" would rule out "no new constant named MAGIC" (*). If a "pure bugfix" happens to break something as well, we can atleast find out what it fixed in return, and then probably find that the fix justified the breakage. Regards, Martin (*) There are also new constants AT_BEGINNING_STRING, but it appears that it was introduced as response to a bug report.
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4