Functionality looks good! I'll leave it to Kian-Tat Lim to rule on whether python 3 is OK at this point.

I thought about commenting on Python 3, but urllib is one of those painful packages that changes between 2.7 and 3. Since this is new code that won't be run by end users I didn't see a problem with it being python3 only. It's not really any different to the ruby code that's included in some of the CI system.

I generally agree that tools can use whatever languages are appropriate. I'm a little worried about the profusion of customization languages, however. The more languages that someone working on our developer infrastructure has to know, the harder it will be to find such a person or the more training will be required before they can contribute. It would be nice to have a catalog of all developer infrastructure dependencies, in addition to the code dependencies.

In terms of a ruling for this particular case, I can accept Python 3 because everyone will eventually have to know it anyway. If it were Haskell or Rust or something else it might not be so easy.

In this particular case, since it was a small one-off, and I wasn't sure if I could get 2.7/future/urllib[2] to be forward compatible with python3, I just did it in python3. Its a small amount of code and I'm happy to rewrite it if necessary.

I did actually think about writing it in golang to see what the response might be...