Message149473
| Author |
carljm |
| Recipients |
aronacher, carljm, loewis, vstinner |
| Date |
2011年12月14日.20:45:50 |
| SpamBayes Score |
2.1682733e-06 |
| Marked as misclassified |
No |
| Message-id |
<1323895551.16.0.870771052965.issue11574@psf.upfronthosting.co.za> |
| In-reply-to |
| Content |
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)? |
|
History
|
|---|
| 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 |
|