Have we been adding these kind of wrapper functions to much code already?

I think either this needs some inline documentation or linting as otherwise this will regress again. It also makes this code harder to maintain which isn't great.

six has been used in various places to provide compatibility with python3 in the past few months. I can try to add unit tests that will be run with py36 but it will not cover all the cases I am fixing as I encounter them.

Imo, the right way is to start running some of the tests with py3, not only the lint and unit tests. Would that be ok ?

EDIT: my goal is to run those tests with python3, i think its enough for now to detect regressions.

I had two concerns, regressions and maintainability. It sounds like there's a plan to deal with regressions, but not necessarily maintenance.

Would it be a big ask that for the test files we have an explicit # ensure_str is for the Py2 -> Py3 transition comment alongside/before usage so it's clear why it's there and when it can be removed?

I could add it here but that would be weird to add it only here and not everywhere it's being used.

If you really want comments, I guess I can deal with it ...

Imo everything from the six module is for py2/py3 compatibility as it's the sole purpose of this module and it's well known enough that it should not be a surprise.

I might be an outlier, but the main reason I write Python these days is for these small WPT server scripts. It's certainly new to me.

Is there a dev documentation where I could add what is six and why it's being used?

Maybe add a section to https://github.com/web-platform-tests/wpt/blob/master/docs/writing-tests/python-handlers/index.md?

My point of view is that in the short term we "don't care" about regressions here. Since we don't really have any way to enforce correctness we have to be content to accept that authors can and will land things that don't work with Python 3. Therefore at present we aren't imposing any new requirements on anyone, and there isn't a strong need to add documentation at this stage.

Once we decide that enough code works with Python 3 to make it a going concern we'll need an RFC decision to make Py3 an officially supported environment, and that will require documentation and a strategy to keep things working in both environments (e.g. running the tests in both, linting, etc.).

So this isn't about "not considering documentation important". It's about not blocking forward progress on changes to make the code work in order to deal with issues that can be safely deferred to the time when they are actual requirements.

That said, if there were a docs change PR now I'd accept it as long as it didn't imply that Py3 support was actually required.

Again, my main concern is not regressions, it's maintenance.

I will change the document @annevk pointed me to. Just did not had time yet 👍

@annevk @jgraham just rebased and added a note relative to python3 compatibility in the python handlers doc as requested. Sorry for the time it took, i was pretty busy.

Building the docs:

Warning, treated as error:
/github/workspace/docs/writing-tests/python-handlers/index.md:48:None:any reference target not found: /tools/third_party/six/six.py

@jgraham i've removed the link in the doc because its not really feasible to include a link that refers to something in tools/third_party/*