Code review comment for lp://qastaging/~gz/pyjunitxml/split_test_id_before_parameter

>>>>> Martin [gz] <email address hidden> writes:

    >> Hmm, what are the constraints on a test id ?
    > Effectively none, but in practice tests will normally be
    > identifiers joined by dots:
    > <http://docs.python.org/reference/lexical_analysis.html#identifiers>

    >> 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.

Meh, of course, why did I read this find as a rfind...

    >> 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.will

    > 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.

Meh for you this time :-p Why would it break ?

It will instead works for [] "" '' {} in addition to '()'. Any descent
scanner (which can do an indirection through a table of valid chars vs a
char comparison) shouldn't make such a difference in performance
compared with the range copyings that will follow.

Bah, maybe I've used perl too much:

  ($class, $test) = $id =~ /^([.\w]+)\.(\w+.*$)/

No useless variables, no if, no split, no slice, no nuthin :)

P.S.: No religious war intended, I love python and use emacs :-P