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). |
|
| History | |||
|---|---|---|---|
| Date | User | Action | Args |
| 2013-11-07 12:23:12 | ncoghlan | set | recipients: + ncoghlan, lemburg, vstinner, benjamin.peterson, meador.inge, serhiy.storchaka |
| 2013-11-07 12:23:12 | ncoghlan | link | issue17823 messages |
| 2013-11-07 12:23:12 | ncoghlan | create | |