6 ms·
The following situation happens with other data than just unicode. This seems an argument for static typing in general. The reason this approach is problemat
by thu 14y ago
The following situation happens with other data than just unicode. This seems an argument for static typing in general.
The reason this approach is problematic is that it means the traceback for an unexpected UnicodeDecodeError or UnicodeEncodeError in a large Python 2.x code base almost never points you to the code that is broken. Instead, you have to trace the origins of the data in the failing operation, and try to figure out where the unexpected 8-bit or Unicode code string was introduced. By contrast, Python 3 is designed to fail fast in most situations[...]
- qznc 14y agoI agree that static typing would helps for such bugs. However, not "in general". The general problem is that bogus data leads to an irreparable situation. To fix that bug, you have to find out who broke the data. Consider for example, a circle in a linked list. You would need quite an expressive type system to prevent that statically (dependent types might suffice? Theorem provers are the ultimate hammer).
- zanny 14y agoDifferent implementations for different use cases in different situations :P
- DannoHung 14y agoUhh, how would you make a linked list with a circle in it with the Haskell List type?
- dbaupp 14y agoa = 1:a
- ufo 14y agoThis trick is often called "Tying the Knot", if anyone is interested.
- qznc 14y agomakeCircle rst = rst ++ makeCircle rst The thing is that a circular list is actually an infinite list in Haskell. ;)
- ufo 14y agoThis is not a real circular list though, since it does not tie the knot as in dbaupp's comment.
- DannoHung 14y agoIf you want to prevent that then you want to take general recursion out of your programming language and if you're gonna do that you might as well make it Turing incomplete. These aren't "circles" per se, they are partially evaluated recursive structures. If you expand them you end up with evaluated list structures that are non-self referential.
- gardentheory 14y agoWell the lighter solution and more Pythonic solution is strong typing. If a Unicode string and a byte string could not be combined then the problem would not exist AFAIK. For example "a" + 1 is an error, why is u"a" + "s" not an error?
- xerula 14y agoBut b"s" + "a" is an error in Py3.
- qznc 14y agoThis just gives a different error message. It does not help to find the error source. The programmer would probably just try to fix it via str(u"a")+"s" or u"a" + unicode("s").
- masklinn 14y ago> For example "a" + 1 is an error, why is u"a" + "s" not an error? "a" + b"s" is an error in Python 3.
- gardentheory 14y agoSorry, that was my point. Strengthening the types in python3 solves the problem without static typing being needed at all.
- masklinn 14y agook. Static types solve it earlier though, especially for little-exercised code paths which could be forgotten or missed in testing.
- slurgfest 14y agoIt is an argument for failing fast in general. Static typing isn't guaranteed to pick up every mistake at its origin, because far from every mistake is of the "int rather than string" variety. Since you have brought up the general case, the origins of many bugs involve something sophisticated going wrong which would require you to encode much of your program (hopefully not too redundantly) into a Turing-complete type system. Rather than stuffing square pegs into round holes, you could just write the appropriate error handling code (or even just asserts).
- earl 14y agoPlease: alias hncomment='fold -w 77 -s | sed "s/^/ /" | pbcopy' use: echo "blah blah blah" | hncomment command-v Thus: The reason this approach is problematic is that it means the traceback for an unexpected UnicodeDecodeError or UnicodeEncodeError in a large Python 2.x code base almost never points you to the code that is broken. Instead, you have to trace the origins of the data in the failing operation, and try to figure out where the unexpected 8-bit or Unicode code string was introduced. By contrast, Python 3 is designed to fail fast in most situations[...]