On 11/14/2013 7:41 PM, Chris Barker wrote: > On Thu, Nov 14, 2013 at 3:58 PM, Steven D'Aprano <steve at pearwood.info> wrote: > >> It's not a given that the current behaviour *is* a bug. > > I'll concede that it's not a bug unless someone said somewhere that > unicode messages should work In particular, what does the reference manual say. > .. but that's kind of a semantic argument. Given that committing a patch to an existing version is a binary action -- done or not, we have to have a binary semantic decision, 'bug' or not, even when the best answer is 'sort of'. We cannot 'sort of' apply a patch ;-). > I have to say it's a very odd choice to me that it suppresses the > message, rather than raising an encoding error, like what happens > everywhere else the default encoding is used. An encoding exception is raised but ignored. Exception handling has changed in some details in 3.x. Sometimes two sensible actions interact in certain contexts to produce an odd result. > In fact, I noticed that the message can be anything that can be > stringified, which makes it particularly wacky that you can't use a > unicode object. You can, as long as it can be stringified with the default args. If it cannot be, then convert it yourself, with the alternative you choose (raise or substitute). > Is this something that could be improved or is the current behavior > the best we could have, given the limitations of strings an unicode in > py2 anyway? From our (core developer viewpoint) that is the wrong question. 2.7 does not get enhancements. The situation would be different if there were going to be a 2.8. -- Terry Jan Reedy
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4