Ja würde ich auch machen ne 2te Config Datei anzulegen für 'wxFileHistory()'. Naja, hängt aber auch davon ab ob du schon nen wrapper für die config klasse aus deinem link geschrieben hast.
Ich bin erst durch den Thread hier darauf aufmerksam geworden das wx selber was mitbringt für INI-Dateien. Leider zu spät, da ich schon nen Wrapper geschrieben habe der gut läuft und auch berücksichtigt ob der wert in einer INI, zu einer Variablen, auch vom Richtigen Datentype ist

Falls einer z.B. in der INI für z.B. 'window_size' nen string statt nen tuple Wert schreibt. Das würde dann zum beispiel, wenn ich nen Frame initialisieren will, ne exception werfen. In Grunde kümmert sich die Klasse (Wrapper) darum dass die Werte in den richtigen Datentype Konvertiert werden. Falls die Konvertierung fehl schlägt wird der entsprechende wert auf default gesetzt und gibt nen log aus (ohne Exception!!), den man sich anzeigen lassen kann oder auch nicht. Somit wird die Initialisierung nciht gestört udn der User erhält auch kein unnötigen Traceback mit den er höchst wahrscheinlich nichts anfangen kann
Ich denke mal das wxConfig nicht so flexible ist(?). z.B. gibt ja config.ConfigParser alles als string zurück, obwohl jede option in der section von einem bestimmten type sein soll. Man muss sich dann selber um ne Konvertierung kümmern, wenn man nen wert von ne option hohlt. Ich denke das sollte auch bei xwConfig nicht anders sein. Daher für mich zu unflexible.
Was ich damit sagen will ist, kuck dir erstmal an wie leistungsfähig die Klasse überhaupt ist von wxConfig und wxFileHistory. Wenn es nicht deinen Anforderungen entspricht, ist es mMn durchaus legitim das Rad neu zu erfinden, wenn das Rad dadurch noch runder wird!
my 2 cents