443,846 Members | 1,872 Online
Need help? Post your question and get tips & solutions from a community of 443,846 IT Pros & Developers. It's quick & easy.

# Complex Nested Dictionaries

 P: n/a To list, I'm trying to figure out the best approach to the following problem: I have four variables: 1) headlines 2) times 3) states 4) zones At this time, I'm thinking of creating a dictionary, headlinesDB, that stores different headlines and their associated time(s), state(s), and zone(s). The complexity is that each headline can have one or more times, one or more states, and one or more zones. However, there can only be 1 zone per time, and 1 zone per state. What is the best way to tackle this particular problem? Here's an example of the complexity: Let's say we have a "High Wind Warning" for our headline or hazard. In addition, there are currently two "High Wind Warnings" in effect. The first goes from Tonight through Friday morning (i.e., I'll probably store the begin/end times in seconds from 1/1/1970). It affects three counties all in the state of Oregon: ORZ047, ORZ048, and ORZ049. The second High Wind Warning is in effect from Friday at Noon through Friday evening. It affects two counties in two separate states: ORZ044 in Oregon and WAZ028 in Washington. Here's the flow chart: High Wind Warning --> time1 --> state1 --> zone1, zone2, zone3 | --> time2 --> state1 --> zone4 --> state2 --> zone5 Keep in mind, each headline or hazard can have multiple times. Each time will have one or more states with each state containing one or more zones. Is there a better way than a dictionary. As mentioned above, the headline or hazard is the key I'll be extracting all the information from. Thanks in advance, Tom Jul 18 '05 #1
9 Replies

 P: n/a In article <40******@news.bmi.net>, "T. Earle" wrote: ...High Wind Warning --> time1 --> state1 --> zone1, zone2, zone3 | --> time2 --> state1 --> zone4 --> state2 --> zone5Keep in mind, each headline or hazard can have multiple times. Each timewill have one or more states with each state containing one or more zones.Is there a better way than a dictionary. As mentioned above, the headlineor hazard is the key I'll be extracting all the information from. If you really only want to look up data by headline, then a dictionary of dictionaries or nested lists or some other kind of collection is easy and should suffice. For instance: warndict["High Wind Warning"] = ( (time1, { state1: (zone1, zone2, zone3), state2: (zone1, zone3), }), (time2, {...}), ) However, I suspect you will also want to be able to locate data by state, time or zone. If that is true, I really think you should consider storing the data in a relational database. It sounds like a perfect match to your problem. Python has some nice interfaces to various databases (including PostgreSQL and MySQL). -- Russell P.S. if you do go with the dictionary, note that it is very easy to make a variant dictionary that defines a[key] = foo to mean "if list a[key] exists, then append foo to that list, otherwise create a new list with foo as its only element" (in fact my RO package contains just such a class: RO.Alg.MultiDict -- see ) Jul 18 '05 #3

 P: n/a Russell, If you really only want to look up data by headline, then a dictionary of dictionaries or nested lists or some other kind of collection is easy and should suffice. For instance: warndict["High Wind Warning"] = ( (time1, { state1: (zone1, zone2, zone3), state2: (zone1, zone3), }), (time2, {...}), ) This definitely seems to be the structure I've been looking for or at least have in mind. Since I'm no expert, could offer some code examples on how to create this structure on the fly? However, I suspect you will also want to be able to locate data by state, time or zone. If that is true, I really think you should consider storing the data in a relational database. It sounds like a perfect match to your problem. Python has some nice interfaces to various databases (including PostgreSQL and MySQL). My first inclination was to go with a database; however, I thought about it and concluded there may be too much variability each time the program is executed. For example, there will be times when there are no headlines; other times, there will be numerous headlines. Because of this variability, the database would have to be created from scratch each time the program is ran. As a result, would a database still be the right choice? I really appreciate your help and suggestions T. Earle Jul 18 '05 #4

 P: n/a T. Earle wrote: Russell,If you really only want to look up data by headline, then a dictionaryof dictionaries or nested lists or some other kind of collection is easyand should suffice. For instance:warndict["High Wind Warning"] = ( (time1, { state1: (zone1, zone2, zone3), state2: (zone1, zone3), }), (time2, {...}),) This definitely seems to be the structure I've been looking for or at least have in mind. Since I'm no expert, could offer some code examples on how to create this structure on the fly? For something very much (but not quite) like the above: warndict['High Wind Warning'] = { time1: { state1: [zone1, zone2, zone3], state2: [zone1, zone3]}, time2: {...}, ...} can be built with something like: warndict = {} for headline, time, state, zone in somesource: timedict = warndict.setdefault(headline, {}) statedict = timedict.setdefault(time, {}) stateentry = statedict.setdefault(state, []) stateentry.append(zone) My first inclination was to go with a database; however, I thought about it and concluded there may be too much variability each time the program is executed. For example, there will be times when there are no headlines; other times, there will be numerous headlines. Because of this variability, the database would have to be created from scratch each time the program is ran. As a result, would a database still be the right choice? It really depends on the volume of data and the kinds of searches. Anything under a thousand or so entries will be searchable by simple brute force in reasonable time, so internal data structures may well be the way to go. -- -Scott David Daniels Sc***********@Acm.Org Jul 18 '05 #5