Yes, it did change the behavior of the test. I probably should have changed the comment.

This is weird because it seems that the behavior of Cornice (or maybe Pyramid) is a little bit different in Python 3 and I haven't been able to figure out why. You might notice that I also removed or changed some other test conditions from this method (see https://github.com/mozilla-services/cornice/pull/111#issuecomment-13413169) -- this is because they fail in Python 3 and I haven't figured out why. I suspect that whoever wrote the tests might have observed the behavior of Cornice/Pyramid under Python 2 and wrote tight tests that characterized that behavior. So there might be tests here that are doing a bit more than testing what the specified behavior of Cornice is; they might be testing things that aren't really guaranteed by Pyramid/Cornice but happen to be true in Python 2. For instance, I don't know if it's really an advertised/specified feature of Cornice that if you declare a view function with multiple `@service2.get` decorators with `accept` params, that the outer decorator is guaranteed to take precedence if the client doesn't specify a preference in the `Accept` header (as a Cornice user, personally I don't care; I expect the user to specify their preference in the `Accept` header if they care). The test kind of implies that using the outermost declaration is the expected behavior, but I don't know if the code makes an effort to make that be the case or if that was intended to be a feature. It seems to be true in Python 2 but not in Python 3, which makes me think that the fact that it worked in Python 2 is some artifact of some implementation detail of Python 2, like the order in which dictionary keys are returned or something.

So not sure what to do here. I don't think I have the time to dig into why this behaves differently in Python 2 vs. Python 3 and I don't know if it's even worth it to do so, if it's not an important feature. Someone more familiar with the internals of Cornice might be able to figure it out easily, if this is an import feature to preseve.

Otherwise, I wonder if I should just change the comment here to reflect that either one of the two content types might be returned.