dictionary/hash and '1' versus 1

[Paddy]

On Jan 4, 3:50 pm, "Reedick, Andrew" <jr9... at ATT.COM> wrote:
> > From: Stephen Hansen [mailto:apt.shan... at gmail.com]
> > Sent: Thursday, January 03, 2008 7:39 PM
> > To: Reedick, Andrew
> > Cc: python-l... 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.

There are many character strings that contain numeric characters that
are not necessarily to be interpreted as an int or a float, such as
string representations of IP addresses, or numbers to other bases than
ten, complex numbers, telephone numbers, ...
You need to validate your input and convert and pass around the
correct type of data. Perl inherited this automatic conversion between
strings and numbers from simple shell scripting and the AWK language
that was around before Perl. I find that the follow-on need to have
separate comparisons for numbers or strings to be awkward in Perl.

>
> > 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

Not really, it seems to me to be going the exact opposite way with
languages with automatic type conversions being seen as not suited for
larger programs.

>
> > 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.
>