SRE: what to do with undocumented attributes?
at this time, SRE uses types instead of classes for compiled patterns and matches. these classes provide a documented interface, and a bunch of internal attributes, for example: RegexObjects: code -- a PCRE code object pattern -- the source pattern groupindex -- maps group names to group indices MatchObjects: regs -- same as match.span()? groupindex -- as above re -- the pattern object used for this match string -- the target string used for this match the problem is that some other modules use these attributes directly. for example, xmllib.py uses the pattern attribute, and other code I've seen uses regs to speed things up. in SRE, I would like to get rid of all these (except possibly for the match.string attribute). opinions? </F>
Andrew wrote:
RegexObjects: code -- a PCRE code object pattern -- the source pattern groupindex -- maps group names to group indices
pattern and groupindex are documented in the Library Reference, and they're part of the public interface.
hmm. I could have sworn... guess I didn't look carefully enough (or someone's used his time machine again :-). oh well, more bloat... btw, "pattern" doesn't make much sense in SRE -- who says the pattern object was created by re.compile? guess I'll just set it to None in other cases (e.g. sregex, sreverb, sgema...) </F>
at this time, SRE uses types instead of classes for compiled patterns and matches. these classes provide a documented interface, and a bunch of internal attributes, for example:
RegexObjects:
code -- a PCRE code object pattern -- the source pattern groupindex -- maps group names to group indices
MatchObjects:
regs -- same as match.span()? groupindex -- as above re -- the pattern object used for this match string -- the target string used for this match
the problem is that some other modules use these attributes directly. for example, xmllib.py uses the pattern attribute, and other code I've seen uses regs to speed things up.
in SRE, I would like to get rid of all these (except possibly for the match.string attribute).
opinions?
Sounds reasonable. All std lib modules that violate this will need to be fixed once sre.py replaces re.py. (Checkin of sre is next.) --Guido van Rossum (home page: http://www.python.org/~guido/)
Fredrik Lundh writes:
RegexObjects: code -- a PCRE code object pattern -- the source pattern groupindex -- maps group names to group indices
pattern and groupindex are documented in the Library Reference, and they're part of the public interface. .code is not, so you can drop it.
MatchObjects: regs -- same as match.span()? groupindex -- as above re -- the pattern object used for this match string -- the target string used for this match
.re and .string are documented. I don't see a reference to MatchObject.groupindex anywhere, and .regs isn't documented, so those two can be ignored; xmllib or whatever external modules use them are being very naughty, so go ahead and break them. -- A.M. Kuchling http://starship.python.net/crew/amk/ Imagine a thousand thousand fireflies of every shape and color; Oh, that was Baghdad at night in those days. -- From SANDMAN #50: "Ramadan"
"FL" == Fredrik Lundh <effbot@telia.com> writes:
FL> hmm. I could have sworn... guess I didn't look carefully FL> enough (or someone's used his time machine again :-). Yep, sorry. If it's documented as in the public interface, it should be kept. Anything else can go (he says without yet grep'ing through his various code bases). -Barry
Fredrik Lundh writes:
btw, "pattern" doesn't make much sense in SRE -- who says the pattern object was created by re.compile? guess I'll just set it to None in other cases (e.g. sregex, sreverb, sgema...)
Good point; I can imagine fabulously complex patterns assembled programmatically, for which no summary could be made. I guess there could be another attribute that also gives the class (module? function?) used to compile the pattern, but more likely, the pattern attribute should be deprecated and eventually dropped. -- A.M. Kuchling http://starship.python.net/crew/amk/ You know how she is when she gets an idea into her head. I mean, when one finally penetrates. -- Desire describes Delirium, in SANDMAN #41: "Brief Lives:1"
participants (4)
-
Andrew M. Kuchling -
Barry A. Warsaw -
Fredrik Lundh -
Guido van Rossum