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
MatchObject is not a hyperlink in the 're' module documentation #50787
Comments
In the re documentation MatchObject is marked up as a class, but since |
Changed all occurrences of :class:`MatchObjects` to :ref:`match-objects` in /Doc/library/re.rst These changes were made to rev 78277. |
Hey all, I think this is ready. Can someone review the patch? |
It would be simpler to add a ".. class:: MatchObject" directive. |
Ryan -- would you take a further look at this? |
Added .. class:: MatchObject and .. class:: RegexObject directives. |
Hey Ryan, I took a look at the diff you attached here. It looks like you did There are some whitespace-only changes -- for example, you remove and then re-insert the line beginning with "The name of the last matched capturing group". Can you re-submit your most recent patch without the unneeded whitespace-only changes? There's a light at the end of the tunnel! |
I've reviewed the patch and do not see any unnecessary whitespace changes in his patch. |
I tried to format the methods of the class(es) as they are formatted in other files, which is why I added the whitespace. I can go back and remove that if that's what would be preferred. |
Er, ignore my comment then! If this is reviewed, can it get committed? |
Fixed in trunk (r79430), release26-maint (r79631), py3k (r79434), and release31-maint (r79435). Thanks for the patch. |
I believe these patches are wrong, at least in part, and should be reverted. 1.The re module no longer has either a class RegexObject or a class MatchObject. (They are now _sre.SRE_Pattern and _sre.SRE_Match.) So This issue came up today on python-list when someone tried "help(re.MatchObject)" and got a module attribute error. I was about to open a new issue when I discovered this one. I recommend changing the re.match entry from "return a corresponding MatchObject instance." to "return a match object" (which is what the current doc string says) and removing all the misleading RegexObject and MatchObject fake-class method prefixes, The prefixes are present in 2.6 and already removed in 2.7. I think they should also be removed from the 3.x docs. (Unless, of course, re is changed to add/reinstate those names, which could only happen in 3.2.)
"(Incompatibility note: in the original Python 1.5 release, if the tuple was one element long, a string would be returned instead. In later versions (from 1.5.1 on), a singleton tuple is returned in such cases.)" were intentionally, not accidentally, removed in 3.0. So I think it a mistake to put revert the removal and that the reversion should be reverted.
|
I'm guessing assigning to Christian was accidental - taking it back for myself. |
How does this patch look? It changes RegexObject to _sre.SRE_Pattern and MatchObject to _sre.SRE_Match. Additionally, references are used to link to those classes generically as "match objects" or "compiled regular expressions" rather than the fake classes used before. |
The patch looks good to me, but I'm not sure if it's a good idea to use _sre.SRE_*. I think these are implementation details and even if they should be mentioned somewhere, they "clutter" the doc IMHO.
Yes, they should be removed.
If it's possible to specify a default value the [] should be avoided. |
I didn't actually want to use _sre.SRE_* but I'm not exactly sure how to hide it. It's more correct that way, but it takes this issue the wrong direction by exposing it. I think it should be denoted as a class but with a generic name, if that's even possible. It would actually be nice if the lines "class _sre.*" were just invisible. |
Please note that my original suggestion was to make them *section* links (:ref:s). As Terry says, they are not real classes and should not be marked up as such. Nor should the internal class names be exposed. Terry: [] notation is 2.x, they should all be gone (with the possible exception of a few C functions) in the 3.x docs. |
Should be fixed now in r83218. I've removed the "class" directives, and put generic class name substitutes "regex" and "pattern" in the method descriptions, like we do for "contextmanager.__enter__". I've also removed the compatibility info, and removed [] style arguments where feasible. |
I have opened a new bpo-16760 for regex HOWTO. |
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:
bugs.python.org fields:
The text was updated successfully, but these errors were encountered: