Maric Michaud <[EMAIL PROTECTED]> wrote: >I don't see a use case where a python programmer should need a >dictionnary "that will be probably big" but can't predict what keys will be >in.
I've recently been working on an app with precisely this characteristic, although there were enough other bottlenecks that the cost of growing the dict as needed was irrelevant. (Read ~2m items from csv file, compare them with items in a database and populate assorted dictionaries based on the result of that comparison for subsequent processing. You can make a reasonable guess, and have a definite upper bound, on the sizes of the dictionaries cheaply right at the start, but you don't know what the keys in each are going to be until you discover them through the comparison of file and DB.) -- \S -- [EMAIL PROTECTED] -- http://www.chaos.org.uk/~sion/ ___ | "Frankly I have no feelings towards penguins one way or the other" \X/ | -- Arthur C. Clarke her nu becomeþ se bera eadward ofdun hlæddre heafdes bæce bump bump bump
-- http://mail.python.org/mailman/listinfo/python-list
