Lars: I will check the history to see if there is a reason (there is probably none) and apply your patch, thank you.

Jason: Thanks for the input.

> It's not obvious to me what the encoding should be. Python and the tarfile module can
> accept unicode filenames.
Note that distutils2 supports back to 2.4, which may not be as convenient.

> It seems that only the gzip part of tarfile fails if a unicode name is passed.
OK.

> Encoding to 'utf-8' or the default file system encoding doesn't seem right (as the
> characters end up getting stored in the gzip archive itself).
I don’t understand.

> Additionally, encoding as 'utf-8' would cause the file to be created with a utf-8 filename,
> which would be undesirable.
Why?

> So in the current repo, I've created a check to convert the filename to ASCII. If it can be
> converted to ASCII, it is converted and passed through to tarfile. This should address the
> majority of users who have thus encountered this issue. For those who wish to use non-ascii
> characters in project names or versions, one will have to use Python 3 or wait until #13639
> is fixed.
The problem is that even in the latest PEP (345), the characters allowed in a project name are under-specified.  I don’t know if restricting to ASCII-only is acceptable.

> Please review the enclosed patch.
I will.

> Since one test fails (and is known to fail), should it omitted? Can it remain but be marked as
> "expected to fail"?
Is it the test with non-ASCII characters?  If there’s hope to fix it later, you can include it and mark it @unittest.expectedFailure.