Python: Wie viel Code packt man in ein try/except

[Kaj G. (Firma: RUB) (bloody)]

Joa, eigentlich ganz einfach Frage:
Wie viel Code packt man in ein try/except?

Kommt in das try nur die eine Funktion rein, die eine Exception auslösen 
kann, oder auch alles danach?
So:

def find_files(path):
    file_list = []
    try:
        files = os.listdir(path)
    except FileNotFoundError:
        return file_list

    for f in files:
        if os.path.isfile(path + f):
            file_list.append(f)

    return file_list

Oder eher so:

def find_files(path):
    file_list = []
    try:
        files = os.listdir(path)
        for f in files:
            if os.path.isfile(path + f):
                file_list.append(f)
    except FileNotFoundError:
        pass

    return file_list

Wie handhabt Ihr das?

Grüße

[Jim M. (turboj)]

Das kommt darauf an(tm).

Zum Bleistift ob "os.path.isfile()" auch noch 'ne Exception werfen kann 
(bei Symlink o.ä).

[Sascha W. (sascha-w)]

Wenn Code auf das Ergebnis der Funktion welche die Exeption auslösen 
kann angewiesen ist dann kannst du den auch gleich mit dort 
reinschreiben damit er nich mit ausgeführt wird.
Wenn deine Funktion bei einem Fehler allerdings sowieso abgebrochen 
wird, dann kannst du den Code auch ausserhalb stehen lassen und deine 
Funktion in der Exception beenden.
Bei deinem Beispiel ist die 1. Variante eher schlecht, wenn die Funktion 
noch andere als die abgefangene Exception auslösen kann.

Sascha

[Noch einer (Gast)]

Wie von Sascha bereits begründet - Alles ins try packen.

Ein return mitten in der Funktion ist ja verpönt. Trotzdem empfinde ich 
ein "return []" im except als die klarste Lösung. Bei dem "return 
file_list" und dem "pass" sieht man nicht, ob eine teilweise gefüllte 
Liste geliefert wird.

[porgamer (Gast)]

Noch einer schrieb:
> Ein return mitten in der Funktion ist ja verpönt.

Nur von Schwätzern.

[Imonbln (Gast)]

Python biete noch eine 3 Möglichkeit, das try kann ein else haben welche 
ausgeführt wird wenn die execption nicht auslöst. Soweit ich das 
verstanden habe ist die Design Idee dahinter genau die das das Except 
nahe beim try steht und man eine Hilfskonstruktion via Flags oder 
ähnliches spart.

def find_files(path):
    file_list = []
    try:
        files = os.listdir(path)
    except FileNotFoundError:
        pass
    else: 
        for f in files:
            if os.path.isfile(path + f):
                file_list.append(f)
    
    return file_list

[Georg (Gast)]

porgamer schrieb:
>> Ein return mitten in der Funktion ist ja verpönt.
>
> Nur von Schwätzern.

Klar, wenn man übersichtlich und lesbar programmiert, könnte ja ein 
anderer den Code verstehen. Sowas muss man als Programmierer unter allen 
Umständen verhindern. So sichert man den eigenen Arbeitsplatz.

Georg

[Slippin J. (gustavo_f)]

Georg schrieb:
> Klar, wenn man übersichtlich und lesbar programmiert, könnte ja ein
> anderer den Code verstehen.

Ich benutze return innerhalb von Funktionen am laufenden Band, gerade 
weil ich es lesbarer finde.

Irgendwelche Conditions prüfen und falls diese nicht erfüllt sind, 
sofort die Funktion mit einem 'return false' oder einem Fehlercode 
verlassen. Das ist doch viel lesbarer und sicherer als das über 
temporäre Variablen und if-else zu lösen. Und das nur, damit am Ende der 
Funktion ein einziges return steht?

[Sheeva P. (sheevaplug)]

Kaj G. schrieb:
>

>         if os.path.isfile(path + f):
>

Peng. {Hint: os.path.isfile(os.path.join(path, f))}

Ansonsten:

def find_file(path):
  try:
    return filter(os.path.isfile,
                  [os.path.join(path, f)
                   for f in os.listdir(path)])
  except FileNotFoundError, e:
    print str(e)
    return list()

oder, wenn Du keine Symlinks dabeihaben willst (os.path.isfile() gibt 
für Symlinks True zurück):

def find_file(path):
  try:
    return filter(lambda x: os.path.isfile(x)
                  and not os.path.islink(x),
                  [os.path.join(path, f)
                   for f in os.listdir(path)])
  except FileNotFoundError, e:
    print str(e)
    return list()

[Kaj G. (Firma: RUB) (bloody)]

Sheeva P. schrieb:
> Peng. {Hint: os.path.isfile(os.path.join(path, f))}
Klaer mich auf, ich seh das Problem nicht.
Windows kann mit '/' im Pfad umgehen und da in path ein '/' am Ende 
steht, sehe ich nichts wo es knallen sollte.
Dazu macht es der zusaetzliche aufruf kein stueck lesbarer. :-/

Dazu ist der uebergebene Pfad an der Stelle immer relativ (Ja, das sieht 
man hier nicht).
Symlinks gibt es an der Stelle auch nicht (ja, ich weiss, das sieht man 
hier nicht). :)

Das mit filter und lambda ist ja auch ganz nett, macht es aber auch 
nicht lesbarer. :-/

[Carl D. (jcw2)]

Kaj G. schrieb:
> Das mit filter und lambda ist ja auch ganz nett, macht es aber auch
> nicht lesbarer. :-/

kann man doch aber was von lernen, wenn man nur in rare cases schlängelt 
;-)

[Sheeva P. (sheevaplug)]

Kaj G. schrieb:
> Sheeva P. schrieb:
>> Peng. {Hint: os.path.isfile(os.path.join(path, f))}
> Klaer mich auf, ich seh das Problem nicht.
> Windows kann mit '/' im Pfad umgehen und da in path ein '/' am Ende
> steht, sehe ich nichts wo es knallen sollte.
> Dazu macht es der zusaetzliche aufruf kein stueck lesbarer. :-/

Wenn aus welchem Grund auch immer mal kein '/', ':' oder '\' am Ende 
steht, funktioniert die Version mit os.path.join() trotzdem korrekt, 
unabhängig von Eingabe und Plattform. Es bleibt aber natürlich Dir 
überlassen, ob Du robusten, fehlertoleranten, wiederverwendbaren und 
pattformunabhängigen Code schreiben willst. ;-)

> Dazu ist der uebergebene Pfad an der Stelle immer relativ (Ja, das sieht
> man hier nicht).
> Symlinks gibt es an der Stelle auch nicht (ja, ich weiss, das sieht man
> hier nicht). :)

Das spielt auch gar keine Rolle.

> Das mit filter und lambda ist ja auch ganz nett, macht es aber auch
> nicht lesbarer. :-/

Ich finde die Variante mit filter() auf die List Comprehension lesbarer, 
aber das ist wohl Gewohnheitssache. YMMV.