> From: Stephen Hansen [mailto:[EMAIL PROTECTED]
> Sent: Thursday, January 03, 2008 7:39 PM
> To: Reedick, Andrew
> Cc: python-list@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
--
http://mail.python.org/mailman/listinfo/python-list
