Paul Moore <pf_moore at yahoo.co.uk> writes: > I was interested in your message as a break from @decorators, but I > couldn't muster the energy to think about the proposal because I've > been reading too many @decorator messages. I guess you won one way and > lost the other :-) @:-) > Maybe a better name would be re.parse? The function has a "feel" of > parsing a string according to a pattern. This is a nice suggestion. The main objection I can think of is that we might be stealing that name from some future idea that would more deserve it. > The only other comment I have is that the semantics seem pretty > complex - I think that in practice, they do more or less what you want > them to, but the description is pretty obscure. Yeah, probably the doc will need to be carefully written, with good examples, to make this go down easily. I hope that for practical cases it'll be relatively straightforward. > And although I can see that the error return has some value, I suspect that > it might actually complicate real use. Someone else suggested throwing an exception instead, which I'm now leaning in favor of, too. > A suggestion - would it be possible to implement re.structmatch as a > pure Python prototype, to thrash out some of the usability questions? > If the function appears valuable in such a form, arguing for > incorporation into the re module would be a lot easier. I suspect that in this case a pure Python implementation might actually be a lot harder than implementing it as a C patch. This is because so much of the work is already done in the current re module; the C patch would probably not be that big. In order to do it in Python I'd end up reimplementing re.match in Python, which I wouldn't look forward to. It's because of this that I'm trying to get as much preliminary comment as I can. Cheers, Mike
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