Message202328
| Author |
ncoghlan |
| Recipients |
benjamin.peterson, lemburg, meador.inge, ncoghlan, serhiy.storchaka, vstinner |
| Date |
2013年11月07日.12:23:12 |
| SpamBayes Score |
-1.0 |
| Marked as misclassified |
Yes |
| Message-id |
<CADiSq7d8qd5BR9+d1FsZO6e1_M_yUh5QAtAAGpKuQ540PHFntA@mail.gmail.com> |
| In-reply-to |
<1383751048.58.0.892493895597.issue17823@psf.upfronthosting.co.za> |
| Content |
After thinking about this some more, perhaps a -3 warning in 2.7 would be a
better solution? That would be more robust, as it could complain any time
unicode.encode produced unicode and str.decode produced str and point users
to the codecs module level functions as a forward compatible alternative.
Producing Py3k warnings when calling unicode.decode and str.encode under -3
would also be appropriate (although those warnings may already exist). |
|