[QUOTE="Ben Morrow"]\n[QUOTE="Quoth Rainer Weikusat"]\n"Someone else wrote it and I know how to get it for free!" may also be a\nsensible approach, but only [BLAH BLAH NIH BLAH][/QUOTE]\n\nOh, do shut up.[/QUOTE]\n\nThis is a design question: How should 'small, mostly static key/ value\ndatabase which occasionally need to be changed be stored and\naccessed?'. The obvious choices would be\n\n- store them in a text file in some "program-independent"\nformat, similar to existing database of this kind, eg,\nservices or protocols\n\n- put the database directly into the code in a suitable way\n\nLink with a third-party module which has a more-or-less up-to-date and\nmore-or-less maintained or unmaintained list internally hard-coded into\nit and provides a more-or-less cumbersome and inefficient interface for\naccessing it seems to be a singularly 'efficient' way to combine the\ndrawbacks of both approaches without providing the advantages of either\nand "But someone else wrote that!" is not really a reason to use the\ninternally hard-coded list in this way: It can be transformed into a real\ndatabase file easily or alternatively, it can be put directly into the\ncode via copy'n'paste, thus yiedling either "can be maintained with\nregard for the code using it, could use different versions on different\noccasions (eg, a localized map), can be used by any kind of code" or\n"everything together in a single file which can be edited easily".\n\nI'd gladly listen to a more rational argument in favour of using the\n'module with hard-coded list in it' than "It already exists".