What's wrong with StdLib.Str?

I was using Str for something once, and people immediately encouraged me to use Re. The explanations for why were quite vague, but I just accepted that it is considered best practice and switched to Re.

But I still want to know why. I’m quite familiar with POSIX BRE and ERE, so that kind of thing doesn’t scare me, but perhaps there are other issues?

The thing I found about Str is that it has a weird interface. In particular, it keeps state - see Str.matched_string, Str.matched_beginning, Str.matched_end and so on. Presumably unless this is thread local state, it is thread unsafe amongst other things (I have never checked to see). Its use of exceptions is also not to everyone’s taste.

1 Like

The main problem with Str is that it relies on global state, and is not thread-safe or reentrant. It’d be much more useful, imho, if there was an opaque context object that stores the results instead of relying on globals.

3 Likes

OK, That does sound nasty. Thanks for the explanation!