3 ms·
I would argue that Python 3 reliability issues should be blamed on inadequate static checking, not on Unicode strictness. If you do foo.decode(), you are intro
by amluto 3y ago
I would argue that Python 3 reliability issues should be blamed on inadequate static checking, not on Unicode strictness.
If you do foo.decode(), you are introducing an operation that can throw. If you are programming in Python for a reliability-critical environment, you should detect this at commit/test time and handle it appropriately.
Rust is every bit as Unicode-strict, but it’s harder to fail to notice that you have a failure path.
Meanwhile, Python 2 will just happily malfunction and carry on. Sure, the code keeps executing, but this doesn’t mean that you will actually get your error message out.
- kragen 3y agopython has a ubiquitous lack of static checking; every other feature added to it must be considered in that context. if on balance it's bad without static checking, it's bad in python the code in question was not doing foo.decode() or foo.encode(). it was writing a string to a file. python 3 inserts implicit unicode encoding and decoding operations in every access to environment variables, file names, command line arguments, and file contents, unless you pass a special binary flag when you open the file, as if you were on fucking ms-dos. all those things are byte strings, and rust and python 2 give you access to them as byte strings. python 3 instead prefers to insert subtle bugs into your program