3 ms·
> inability to play fast and lose with the definition of "string" If that wasn't intentional it's a very fitting typo. In either case it describes perfectly wh
by ygra 13y ago
> inability to play fast and lose with the definition of "string"
If that wasn't intentional it's a very fitting typo. In either case it describes perfectly why Python 3's distinction between text and data (or Unicode and byte strings) is much better than the Python 2 state of affairs which tends to work somewhat until it breaks (similar to string handling in C/C++ when Unicode is encountered).
- masklinn 13y ago> If that wasn't intentional it's a very fitting typo. It wasn't[0], and though I agree I fixed it. > In either case it describes perfectly why Python 3's distinction between text and data (or Unicode and byte strings) is much better than the Python 2 state of affairs Yes, although it really annoys people who work at the boundary or in domains where the distinction is unclear or ill-defined (urls, HTTP headers, environment variables, …). Which is probably why e.g. Armin Ronacher has so many issues with it[1]: the vast majority of his stuff (at least for the libraries he releases) operate across these boundaries. [0] I actually spent a second wondering, and then I got it wrong anyway. [1] http://lucumr.pocoo.org/2014/1/5/unicode-in-2-and-3/ http://lucumr.pocoo.org/2014/1/5/unicode-in-2-and-3/