On 26 Aug, 11:51 pm, chris at simplistix.co.uk wrote: >exarkun at twistedmatrix.com wrote: >>The ability to change the default encoding is a misfeature. There's >>essentially no way to write correct Python code in the presence of >>this feature. > >How so? If every single piece of text in your project is encoded in a >superset of ascii (such as utf-8), why would this be a problem? >Even if you were evil/stupid and mixed encodings, surely all you'd get >is different unicode errors or mayvbe the odd strange character during >display? This is what I meant when I said what I said about correct code. If you're happy to have encoding errors and corrupt data, then I guess you're happy to have a function like setdefaultencoding. >>It may be a major task, but the best thing you can do is find each str >>and unicode operation in the software you're working with and make >>them correct with respect to your inputs and outputs. Flipping a >>giant switch for the entire process is just going to change which >>things are wrong. > >Well, flipping that giant switch has worked in production for the past >5 years, so I'm afraid I'll respectfully disagree. I'd suspect the >pragmatics of real world software are with that function even exists, >and it's extremely useful when used correctly... I suppose it's fortunate for you that the function exists, then. For my part, I have managed to write and operate a lot of code in production for at least as long without ever touching it. Generally speaking, I also don't find that I encounter lots of unicode errors or corrupted data (*sometimes* I do; in those cases, I fix the broken code and it doesn't happen again). Jean-Paul
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