Walter Dörwald wrote:
I'm not sure if this is the right approach.
I think the approach is right, but the implementation is wrong.
The encoding I specify in
setup.py should be independent of the encoding used between distutils
and PyPI to communicate on the wire. I.e. the author (and maintainer)
argument should always be unicode.
"should" is a correct description. It should allow Unicode strings,
which it then should encode to UTF-8 during transmission. The matter
of fact is that the register command as released in 2.4 (and 2.4.1)
doesn't.
When str is passed, this is treated
as any other str in a unicode context, it is decoded using the default
encoding. This would fix another problem: It would make it nearly
impossible to send a request to PyPI with the wrong encoding, because
any encoding problems are sorted out completely on the client side.
distutils should *not* assume that byte strings are in the default
encoding. It is fair to assume they are in ASCII; if the administrator
has changed the default encoding, then this cannot possibly affect
all the setup.py files out there. Also, it is a fact that the
deployed versions of the register command just send byte strings
in setup.py as-is, without trying to do any kind of recoding.
In any case, PyPI now requires that the form submission uses UTF-8,
and refuses anything else. So it *is* impossible to send, say,
Latin-1; whether the client makes that happen by properly encoding
Unicode strings or whether they are in setup.py in the first place
does not matter.
Is there a way to display the HTTP response by PyPI?
Yes, please invoke upload with --show-response.
Editing the package is still broken. The link "edit" on the page
http://www.python.org/pypi/ll-ansistyle/0.6.1 gives:
---
Error...
There's been a problem with your request
exceptions.UnicodeDecodeError: 'ascii' codec can't decode byte 0xc3 in
position 92: ordinal not in range(128)
I see. I'll investigate.
Martin
_______________________________________________
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
