Repository navigation
Scanner class in re module undocumented #49587
Description
| BPO | 5337 |
|---|---|
| Nosy | @birkenfeld, @rhettinger, @benjaminp, @ashemedai, @voidspace |
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:
assignee = 'https://github.com/rhettinger'
closed_at = <Date 2009-05-20.01:31:06.013>
created_at = <Date 2009-02-21.16:56:04.418>
labels = ['docs']
title = 'Scanner class in re module undocumented'
updated_at = <Date 2009-05-20.01:31:06.011>
user = 'https://github.com/voidspace'bugs.python.org fields:
activity = <Date 2009-05-20.01:31:06.011>
actor = 'rhettinger'
assignee = 'rhettinger'
closed = True
closed_date = <Date 2009-05-20.01:31:06.013>
closer = 'rhettinger'
components = ['Documentation']
creation = <Date 2009-02-21.16:56:04.418>
creator = 'michael.foord'
dependencies = []
files = []
hgrepos = []
issue_num = 5337
keywords = []
message_count = 13.0
messages = ['82569', '82658', '84326', '84435', '84447', '84907', '84914', '84930', '86794', '86795', '86796', '88036', '88104']
nosy_count = 7.0
nosy_names = ['effbot', 'georg.brandl', 'rhettinger', 'benjamin.peterson', 'asmodai', 'mrabarnett', 'michael.foord']
pr_nums = []
priority = 'low'
resolution = 'rejected'
stage = None
status = 'closed'
superseder = None
type = None
url = 'https://bugs.python.org/issue5337'
versions = ['Python 2.7', 'Python 3.2']
Activity
voidspace commentedon Feb 21, 2009
There is a useful Scanner class in the re module which is undocumented.
See:
http://mail.python.org/pipermail/python-dev/2003-April/035075.html
http://www.evanfosmark.com/2009/02/sexy-lexing-with-python/
rhettinger commentedon Feb 24, 2009
Any opinions on whether this was intended to be exposed?
birkenfeld commentedon Mar 28, 2009
The class is commented as being "experimental", and the interface
probably could use improvement (it's a bit awkward to subclass Scanner),
but since it's been around for so long, I guess enough people will be
using it that we have to keep it that way and document it.
Opinions?
benjaminp commentedon Mar 29, 2009
I'm sure people are already rely on the intimate details of this class,
so why not?
mrabarnett commentedon Mar 30, 2009
FYI, I did tidy up the class and add a 'scaniter' method when I was
working on issue bpo-2636; it might yet see the light of day if it gets the
go ahead!
birkenfeld commentedon Mar 31, 2009
OK, so we'll wait for that.
rhettinger commentedon Mar 31, 2009
Whether this should be exposed is up to effbot. It's his code. He
knows its limitations and he made the original decision to leave it
undocumented.
mrabarnett commentedon Mar 31, 2009
One of the limitations is that it identifies what matched by using
capture groups, so if the expressions provided contain captures then it
gets confused! :-)
I handled that by 1) rejecting named captures and 2) changing unnamed
captures into non-captures.
ashemedai commentedon Apr 29, 2009
So far effbot hasn't said anything about this. So Frederik, was it
intended to be exposed or not?
voidspace commentedon Apr 29, 2009
Whether it was intended to be exposed or not it is known and used - and
therefore we can't change the API without going through the usual
deprecation process. As it is used and useful it should be documented.
ashemedai commentedon Apr 29, 2009
OK, clear, then I'll see what I can do.
rhettinger commentedon May 18, 2009
This is very old code, without a mature API. Will take a look at
competing recipes to see if this is still the best way of doing this.
Maybe it should return a generator instead of a list. Perhaps there
should be some checking for re's that don't combine well. Also, would
like to see it exercised on a number of common parsing tasks to see how
well it holds up. Better to do this work than to expose what is there
now and get hit with bug reports, feature requests, deprecations, and
cases where is it almost the right tool for the job.
rhettinger commentedon May 20, 2009
Looking back at the original thread, good reasons were expresses for not
documenting this code but just leaving it in as an example.