@naheliegend: Ein paar Anmerkungen zum Code: Typannotation an sich finde ich ja schon doof, aber Rückgabewerte und Variablen als `object` zu annotieren ist das nutzloseste was man sich vorstellen kann. Alles was man in Python an einen Namen binden kann ist ein Objekt. Etwas als `object` zu annotieren bringt als überhaupt keinen Nutzen.
Anstelle des Kommentars ``# Main`` würde man den Code eher in eine `main()`-Funktion stecken und die nur ausführen wenn das Modul als Programm gestartet wurde, aber nicht wenn es importiert wird.
Einige Namen sind nicht gut. Abkürzungen sollte man vermeiden, damit der Benutzer nicht raten muss was der Name bedeutet. Statt `url_sol_7` zum Beispiel besser `solution_url`.
Funktions- und Methodennamen beschreiben in der Regel Tätigkeiten. `loesung` wäre ein guter Name für eine Lösung, aber nicht für eine Funktion die die Lösung berechnet.
Wenn man Funktionen verschachtelt, lassen sich die inneren Funktionen nicht separat testen. Das `search()` *in* `loesung()` definiert wird, macht keinen Sinn.
Warum das Ergebnis von `requests.get()` an den Namen `roh` gebunden wird, verstehe ich nicht. Da ist nichts ”rohes” dran und der griechische Buchstabe wird ja auch nicht gemeint sein‽
Der Wert von `k` im JSON ist bereits eine (ganze) Zahl, da braucht man kein `int()` für. Und eine Liste mit Zahlen `lists` zu nennen ist verwirrend, denn es ist ja *eine* Liste.
Bei `listoo` frage ich mich wieder was mir dieser Name sagen will.
`index1` und `index2` sind ziemlich wahrscheinlich auch falsche Namen, es sei denn die Zahlen *in* der Liste stellen tatsächlich Indexwerte dar. Bei `v1` und `v2` ist es dann umgekehrt — das `v` lässt `value` vermuten, hier sind es dann aber tatsächlich Indizes.
Das `index1` an den Namen `set` gebunden wird macht keinen Sinn. Mal davon abgesehen das `set` schon der Name des eingebauten Mengentyps ist, und deswegen nicht überschrieben werden sollte, macht weder der Name, noch diese Umbennung an sich Sinn.
``if``- oder ``else``-Zweige mit ``pass`` sind sinnlos. Man kann die beiden ``if``\s dann auch zu einem zusammenfassen.
Wenn keine Lösung gefunden wird, dann gibt die `search()`-Funktion *implizit* `None` zurück. Das sollte man *explizit* machen, damit ein Leser nicht denkt das der Fall vergessen wurde oder das Programm an der Stelle noch nicht vollständig ist.
Zwischenstand:
Code: Alles auswählen
import json
import time
import requests
def search(values, k):
for value_a in values:
for value_b in values:
if value_b != value_a and value_a + value_b == k:
return [values.index(value_a), values.index(value_b)]
return None
def loese(challenge_url, solution_url):
challenge = requests.get(url=challenge_url).json()
solution = {'token': search(challenge['list'], challenge['k'])}
response = requests.post(url=solution_url, data=json.dumps(solution))
print(response.text)
def main():
start = time.time()
iteration_count = 100
for _ in range(iteration_count):
loese(
'https://cc.the-morpheus.de/challenges/7/',
'https://cc.the-morpheus.de/solutions/7/'
)
print((time.time() - start) / iteration_count)
if __name__ == '__main__':
main()
Der Code ist nicht besonders effizient wenn keine Lösung gefunden werden kann, weil die Addition kommutativ ist, und deshalb zu viel durchgetestet wird.
Wenn man das Nebenläufig löst, kann es passieren das eine andere Lösung herauskommt als bei einem rein linearen Ablauf. Da ist die Frage, ob das okay ist.
