On 6/24/2010 1:38 PM, Bill Janssen wrote: > > Secondly, maybe the string situation in 2.x wasn't as broken as we > thought it was. In particular, those who deal with lots of encoded > strings seemed to find it handy, and miss it in 3.x. Perhaps strings > are more like numbers than we think. We have separate types for int, > float, Decimal, etc. But they're all numbers, and they all > cross-operate. No they do not. Decimal only mixes properly with ints, but not with anything else, sometime with surprising and havoc-creating ways: >>> Decimal(0) == float(0) False I believe that and other comparisons may be fixed in 3.2, but I know there was lots of discussion of whether float + decimal should return a float or decimal, with good arguments both ways. To put it another way, there are potential problems with either choice. Automatic mixed-mode arithmetic is not always a slam-dunk, no-problem choise. That aside, there are a couple of places where I think the comparison breaks down. If one adds a thousand ints and then a float, there is only the final number to convert. If one adds a thousand bytes and then a unicode, there is the concantenation of the thousand bytes to convert. Or short the result be the concatenation of a thousand unicode conversions. This brings up the distributivity (or not) of conversion over summation. In general, float(i) + float(j) = float(i+j), for i,j ints. I an not sure the same is true if i,j are bytes with some encoding and the conversion is unicode. Does it depend on the encoding? -- 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