pytester linematcher - less error prone api

[RonnyPfannschmidt]

linematcher and result object have apis that fool one easily,

in particular str(matcher) vs matcher.str() (i feel for it and committed a regression that looked fine)

[The-Compiler]

Also see some related discussions in https://github.com/pytest-dev/pytest/issues/95#issuecomment-148647068

[blueyed]

I would also see this to be available for your own tests then (also mentioned in https://github.com/pytest-dev/pytest/issues/95#issuecomment-129660836).

[RonnyPfannschmidt]

id totally love to make linematcher an pypi package avialiable for anyone wanting to use it

[mcsitter]

What's the status on this? It is labeled critical 😃 . Changing the API for the string should be easy and i could do that. See below for that.

With a more precise specification of what functionality is missing maybe providing some usecases, i would be happy to tackle this. It seems as if this is not precisely for handling (just) filenames. Probably also matching output of stdout for example What interaction of string or list[str] with seperators, regex etc. is desired? Maybe one could point to an existing test which could make use of this?

Is str(matcher) or matcher.str() preferred? Since str is buit into python it should probably be the standard. The str method could be deprecated if this helps streamlining.

There should be one-- and preferably only one --obvious way to do it.

[bluetech]

What's the status on this? It is labeled critical

Clearly this is not critical, so I removed this label.

Is str(matcher) or matcher.str() preferred? Since str is buit into python it should probably be the standard. The str method could be deprecated if this helps streamlining.

I have personally did str(matcher) multiple times until I remembered it's .str(). Maybe we should just make it work, I doubt it will break anything.