[Python-Dev] New PyPI broken package editing

"Martin v. Löwis" martin at v.loewis.de
Sun Mar 27 17:21:38 CEST 2005

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)

> 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.


More information about the Python-Dev mailing list