Message149473
Here's an example real-world case where the only solution I could find was to simply avoid non-ASCII characters entirely (which is obviously not a real solution): https://github.com/pypa/virtualenv/issues/201#issuecomment-3145690
distutils/distribute require long_description to be a string, not bytes (so it can rfc822-escape it, and use string methods to do so), but does not explicitly set an output encoding when it writes egg-info. This means that a developer either has the choice to a) break installation of their package on any system with an ASCII default locale, or b) not use any non-ASCII characters in long_description.
One might say, "ok, this is a bug in distutils/distribute, it should explicitly specify UTF-8 encoding when writing egg-info." But if this is a sensible thing for distutils/distribute to do, regardless of user locale, why would it not be equally sensible for Python itself to have the default output encoding always be UTF-8 (with the ability for a developer who wants to support arbitrary user locale to explicitly do so)? |
|
Date |
User |
Action |
Args |
2011-12-14 20:45:51 | carljm | set | recipients:
+ carljm, loewis, vstinner, aronacher |
2011-12-14 20:45:51 | carljm | set | messageid: <1323895551.16.0.870771052965.issue11574@psf.upfronthosting.co.za> |
2011-12-14 20:45:50 | carljm | link | issue11574 messages |
2011-12-14 20:45:50 | carljm | create | |
|