Bob Ippolito <bob at redivi.com> wrote:
>>> Well it's not recomended to mix strings and unicode in the
>>> dictionaries
>>> but if we mix for example integer and float we have the same
>>> thing. It
>>> doesn't raise exception but still it is not expected behavior for
>>> me:
>>>>>> d = { 1.0: 10, 2.0: 20 }
>>> then if i somewhere later do:
>>>>>> d[1] = 100
>>>>>> d[2] = 200
>>> to have here all floats in d.keys(). May be this is not a best
>>> example.
>>
>> There is a strong difference. Python is moving towards unifying
>> number types in
>> a way (see the true division issue): the idea is that, all in all,
>> user
>> shouldn't really care what type a number is, as long as he knows
>> it's a number.
>> On the other hand, unicode and str are going to diverge more and
>> more.
>
> Well, not really. True division makes int/int return float instead of
> an int. You really do have to care if you have an int or a float most
> of the time, they're very different semantically.
Then I'd ask why Python goes through hoops to make sure that hash(1.0) ==
hash(1), in the first place.
Giovanni Bajo
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