@awacker: Okay, jetzt noch einmal eine etwas ausführlichere Kritik.
An einigen Stellen könnten mehr Leerzeichen zur Lesbarkeit beitragen. Üblicherweise setzt man um ``=`` bei Zuweisungen ausserhalb von Parameterlisten Leerzeichen und eines nach Kommata. Das Ende von dem Wörterbuch das an `reps` gebunden wird, ist zum Beispiel IMHO ziemlich unübersichtlich.
Namensgebung ist etwas was einen sehr grossen Einfluss darauf hat wie leicht ein Quelltext zu verstehen ist. Man sollte auf Abkürzungen verzichten die nicht allgemein oder zumindest im Fachgebiet des Programms geläufig sind. Sehr schlecht sind einzelne Buchstaben wenn es sich nicht gerade um numerische Werte handelt. `i`, `j`, `k` und `n` sind für ganze Zahlen nicht unüblich, vor allem „Laufvariablen“. Aber selbst da sollte man überlegen, ob man nicht einen passenderen Bezeichner finden kann. Unpassende Namen sollte man auch vermeiden, wie zum Beispiel `mainfile` — daran wird keine Datei gebunden, sondern ein Dateiname. Funktionsnamen sollten eine Tätigkeit beschreiben. Also zum Beispiel `analyse_hypothesis()` statt `hyp_analysis()`.
Das „slicing“ bei `hypothesis` am Anfang ist Unsinn und hat keinen Effekt. Was dort steht ist: Ich möchte einen Ausschnitt von `hypothesis` der vier Zeichen länger ist als `hypothesis` selbst. Was erwartest Du denn von diesem Ausdruck?
Code: Alles auswählen
In [120]: s = 'ham and eggs'
In [121]: s[0:len(s) + 4]
Out[121]: 'ham and eggs'
In [122]: s[0:len(s) + 4] == s
Out[122]: True
Den regulären Ausdruck kann man etwas kompakter formulieren. Da alle Alternativen mit Ziffern enden, kann man den Teil dort heraus ziehen. Und beim `match()` sind die beiden letzten Argumente überflüssig. Die Methode fängt von sich aus beim Index 0 an.
Beim `replace_all()` stellt sich mir die Frage ob das tatsächlich immer so funktioniert wie es soll. Einträge in einem Wörterbuch sind ungeordnet und die Ersetzungen sind nicht unabhängig von der Reihenfolge. Falls das wie gewünscht funktioniert, kann das also auch Zufall sein. Eine Liste mit Ersetzungspaaren wäre hier sicherer.
Der 'EN DASH' als UTF-8 kodierte Bytefolge ist unschön. Wofür diese Bytefolge steht ist nicht wirklich offensichtlich. Minimal sollte man das durch einen Kommentar oder eine verständlichere Darstellung klarmachen. Beispielsweise ``u'\n{EN DASH}'.encode('utf-8')``. Daraus wird ersichtlich was es für ein Zeichen ist, und in welcher Kodierung.
Noch besser wäre es allerdings, wenn man bei Text auch durchgehend tatsächlich mit Zeichen, also `unicode` arbeitet, statt mit Bytes. Das Umwandeln kann man beim einlesen und schreiben über `codecs.open()` erledigen.
Ungetestet:
Code: Alles auswählen
import codecs
def analyse_hypothesis(hypothesis, encoding='utf-8'):
main_filename = hypothesis + '.txt'
with codecs.open(main_filename, 'r', encoding) as main_file:
sentences = tokenize_sentences(main_file.read())
print len(sentences)
is_hypothesis = re.compile('(H ?|P|Hypothesis |Proposition )\d+').match
replacements = [
('\n', ' '),
('\n\n', ' '),
(u'\n{EN DASH}', ' '),
(' ', ' ')
]
with codecs.open('hyp_' + main_filename, 'w', encoding) as hypothesis_file:
for sentence in sentences:
sentence = replace_all(sentence, replacements)
if is_hypothesis(sentence):
print sentence
hypothesis_file.write(sentence)
