dictionary/hash and '1' versus 1

[Reedick, Andrew]

> From: Stephen Hansen [mailto:apt.shansen at gmail.com] 
> Sent: Thursday, January 03, 2008 7:39 PM
> To: Reedick, Andrew
> Cc: python-list at python.org
> Subject: Re: dictionary/hash and '1' versus 1
>
>
>
> Well one important thing to learn while learning Python is that while the  
> language is dynamically typed-- it is also /strongly/ typed. Every piece
> of data has an explicit type and it doesn't change unless you change it.

	Meh, mixing dynamic and strong typing is a mixed blessing.  You don't find out that you screwed up the data types until the code block is actually executed.  Reminds me of Nostradamus.  He may have predicted the future[1], but the predictions are so vague/convoluted that you can only figure out the predictions in hindsight.


> It relies on duck typing a lot, and doesn't care if you mix and match 
> (even partially) compatible types as long as the operations are there,
> but one type will always be distinct and remain that type until you
> explicitly convert it.
>
> A single integer is distinctly different from a sequence of characters in
> some encoding that may just happen to contain representations of a
> number.... so they'll hash differently :)

	Depends on the context.  The machine encoding may be different, but in human terms they "should" be the same.  Perl managed to achieve an impressive blend of presenting data as human friendly or as machine bits when it made sense to do so.  So much so, that Perl is probably the only language I've used that will do what you mean instead of what you say.  Nice, but frightening in some ways.


> One type will basically never implicitly convert into another type.
>
> To me, this sounds like the function should have converted the type 
> explicitly on return. Or maybe you need to convert it explicitly on
> receipt.

	Type casting is easy, IFF you remember to do so.  The problem was that I missed the fact that one (important) function was returning a string instead of an int, and since Python supports heterogenous data structures, the human has to remember to keep the key's data type homongenous.
	That and Perl does so much automatic type conversion in such a sensible way, that I stopped worrying about mixing data types, which is making the Python transition a tad more error prone.  Because of Perl, I almost consider automatic type casting to be the next "you don't have to manage your own memory" that people loved about Java.  =O


> But if you are in a use-case where you really don't care and only 
> want to hash strings, you can create a dict subclass easily that
> overrides __setitem__ to always str() the input. Check out the
> UserDict class.

	UserDict looks like it could be useful.  Thanks for the info.


> A similar method lets you make 'case-insensitive' dicts, for example.
>
> Were such a thing to happen automagically, you could get some 
> weird situations, such as "assert (key in dict) == (key in dict.keys())" 
> failing.

	I'm assuming that you would just need to overload the 'in' operator and .keys() method to be case insensitive also.




[1]  No, he didn't.


*****

The information transmitted is intended only for the person or entity to which it is addressed and may contain confidential, proprietary, and/or privileged material. Any review, retransmission, dissemination or other use of, or taking of any action in reliance upon this information by persons or entities other than the intended recipient is prohibited. If you received this in error, please contact the sender and delete the material from all computers. GA625