I take it the bug is that .*? is implemented recursively rather
then iteratively? I wondered if .*? was broken, but it yields the
right answer for short input strings.
The case of * applied to a fixed width term could be implemented
interatively, ".*", "[axz]*" etc. But variable sized terms would
need a record of what they matched for back tracking. For example
"(\w+\s+)*". The compiler can figure these differences out.
Using a back tracking stack allocated from the heap would reduce
the memory used to run the search at the cost of code complexity.
Once the bug is fixed the canned message will only need to cover
the case of greed repeats * and {n,} encountering an input string
line that is too long?
I'm working on a regex parser/engine for Barry's Emacs and these
design problems are fresh in my thoughts.
Barry
-----Original Message-----
From: python-dev-admin@python.org [mailto:python-dev-admin@python.org]On
Behalf Of Tim Peters
Sent: 02 June 2002 23:04
To: python-dev@python.org
Subject: RE: [Python-Dev] "max recursion limit exceeded" canned
response?
[Skip Montanaro]
> How would we go about adding a canned response to the commonly submitted
> "max recursion limit exceeded" bug report?
[Martin v. Loewis]
> Post the precise text that you want to see as the canned response, and
> somebody can install it.
I don't think any canned answer will suffice -- every context is different
enough that it needs custom help. I vote instead that we stop answering
these reports at all: let /F do it. That will eventually provoke him into
either writing the canned response he wants to see, or to complete the
long-delayed task of removing this ceiling from sre.
_______________________________________________
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
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