dictionary/hash and '1' versus 1

[Stephen Hansen]

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


Frightening is the word I'd use-- nice is not ;-)

For me, the thought that "assert (1 == '1') is True" should pass is alien
and alarming to the point of rising to, "That's obviously wrong." Of course,
I know other languages do things their own way .. so to each their own :)
Python's philosophy of "explicit is better then implicit" is one that I
appreciate and have found to be a saving grace in maintaining huge systems
over the last few years.

I could so see myself learning perl and sending the exact inverse message to
a perl mailing list; I actually /have/ code which relies upon the exact case
of numbers and strings never being implicitly converted to compare to
each-other. :)

Different starting point in mindset, is all.

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

This is true; there does need to be a more aware/complete understanding of
the input/output API of the code you're using.

       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


Heathen. ;-) I prescribe meditation, green leaf tea, and continual chanting
of the sacred scroll provided by "import this" until this unwholesome
adoration of black magic practices has been cleansed from your mind.

In all seriousness, I can see the appeal; but prefer the strongly typed
world. Partly because of where I use it, when we do a LOT of CORBA
communication (which is massively strongly typed in and of itself),
protocols and careful data management/conversion. Partly habit. I don't ever
worry about mixing data types; I'm just aware of what type things are
(although often in vague trusting ways such as 'I am sure you are a file;
please do not disappoint me').

In the end I highly doubt requiring explicit conversions has a notable
negative on productivity or makes the code/logic much bigger or more
complicated... whereas not having to manage one's own memory is a fairly
huge savings :)

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

For my case-insensitive dict I didn't need to modify keys at all. I wasn't
interested in it being "case-preserving"; all keys were lower cased on
insert(via .update, __setitem__, or .setdefault), and the 'check' value when
testing or fetching was lowercased for comparison (via __contains__,
__getitem__, and .get)

For example, a less functional version:

  class caseinsensitivedict(dict):
      def __contains__(self, key):
          return dict.__contains__(self, key.lower())
      def __getitem__(self, key):
          return dict.__getitem__(self, key.lower())
      def __setitem__(self, key, value):
          return dict.__setitem__(self, key.lower(), value)

  >>> cid = caseinsensitivedict()
  >>> cid['This'] = 5
  >>> cid
  {'this': 5}
  >>> cid.keys()
  ['this']
  >>> print 'THIS' in cid:
  True

I could do a case-preserving one, but it wasn't needed for the solution.

--Stephen
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-list/attachments/20080104/2553d3ec/attachment-0001.html>