Mailing List Archive

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>
Re: SRE: what to do with undocumented attributes? [ In reply to ]
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>
Re: SRE: what to do with undocumented attributes? [ In reply to ]
> 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/)
Re: SRE: what to do with undocumented attributes? [ In reply to ]
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"
Re: SRE: what to do with undocumented attributes? [ In reply to ]
>>>>> "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
Re: SRE: what to do with undocumented attributes? [ In reply to ]
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"