> I've got the feeling that the (par1,par2) addition is quite bzr specific
> and I don't know if we even enforce the constraints that parameter strings
> should not embed
> any funny stuff (say a '(') which will break your fix as well.
Actually this way shouldn't care about anything in the parameter as it's searching for the first opening bracket and never looking beyond it. I agree this is probably somewhat bzr specific, but should at least be harmless on less fancy setups.
> 14 + class_end = test_id.rfind(".", 0, test_id.find("("))
>
> So I'd be very tempted to ask for a better way than test_id.find("(") to
> identify
> a valid python identifier at the *start* of the test id and then, and only
> then,
> extract the class from that.
Well, [^._0-9a-z-A-Z] would be an option, but is probably overkill and *more* likely to break on other suite's fancy id schemes.
> Hmm, what are the constraints on a test id ?
Effectively none, but in practice tests will normally be identifiers joined by dots: docs.python. org/reference/ lexical_ analysis. html#identifier s>
<http://
> I've got the feeling that the (par1,par2) addition is quite bzr specific
> and I don't know if we even enforce the constraints that parameter strings
> should not embed
> any funny stuff (say a '(') which will break your fix as well.
Actually this way shouldn't care about anything in the parameter as it's searching for the first opening bracket and never looking beyond it. I agree this is probably somewhat bzr specific, but should at least be harmless on less fancy setups.
> 14 + class_end = test_id.rfind(".", 0, test_id.find("("))
>
> So I'd be very tempted to ask for a better way than test_id.find("(") to
> identify
> a valid python identifier at the *start* of the test id and then, and only
> then,
> extract the class from that.
Well, [^._0-9a-z-A-Z] would be an option, but is probably overkill and *more* likely to break on other suite's fancy id schemes.