(a copy was sent to comp.lang.python by mistake;
sorry for that).
Andrew M. Kuchling <akuchlin@mems-exchange.org> wrote:
> I don't think that will be a problem, given that the Unicode engine
> would be a separate C implementation. A bit of 'if type(strg) ==
> UnicodeType' in re.py isn't going to cost very much speed.
a slightly hairer design issue is what combinations
of pattern and string the new 're' will handle.
the first two are obvious:
ordinary pattern, ordinary string
unicode pattern, unicode string
but what about these?
ordinary pattern, unicode string
unicode pattern, ordinary string
"coercing" patterns (i.e. recompiling, on demand)
seem to be a somewhat risky business ;-)
</F>
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