I don't think Python unittest cares about the order of (expected, actual). The docs just call them (first, second) and the messages generated by a failure will say something like
AssertionError: eng1 != eng
I use the same order for JUnit and unittest with no problems.
If you used a consistent naming convention for your params, is there a reason why you can't just do a search and replace in files to fix all your unit tests? Any decent modern ide offers this feature.
The order of the arguments are consistent - but the names used are different. 
Comment about 'first', 'second' is correct. I've corrected the post.
Fuzzy
The JUnit convention of having the message first has always struck me as dumb, and does not really work in Python.
It it dumb because it breaks readability - assertEqual("some message", expected, actual) reads like it is asserting that "some message" is equal to 'expected'. Also the message parameter is optional, so it is not instantly obvious whether the in assertion assertEqual("succeeded", x) the string "succeeded" is a message or a value to be compared - you have to read the entire method call to see how many parameters there are. This may seem trivial, but if you have a lot of assertions in a file it is going to add to the cognitive load of reading it. It also makes it very hard to write a script to extract or manipulate the parameters - for example if you wanted to swap over all the 'expected' and 'actual' parameters.
It doesnt work in Python because you often want to leave off the message and just have assertEqual(expected, actual) - this is more informative in practice since the unittest default message tells you what the values actually are, but if you add a message it doesnt. In Python optional parameters have to go at the end of a function declaration, so the message parameter has to be at the end, where it belongs.
Commenting by HaloScan
