Devo passare i nomi dei file da aprire o aprire i file?

Supponiamo che io abbia una funzione che fa le cose con un file di testo - ad esempio, legge da esso e rimuove la parola "a". Potrei passargli un nome di file e gestire l'apertura / chiusura nella funzione, oppure potrei passargli il file aperto e aspettarmi che chiunque lo chiami si occupi di chiuderlo.

Il primo modo sembra un modo migliore per garantire che nessun file venga lasciato aperto, ma mi impedisce di usare cose come gli oggetti StringIO

Il secondo modo potrebbe essere un po 'pericoloso - nessun modo di sapere se il file verrà chiuso o meno, ma sarei in grado di usare oggetti simili a file

def ver_1(filename):
    with open(filename, 'r') as f:
        return do_stuff(f)

def ver_2(open_file):
    return do_stuff(open_file)

print ver_1('my_file.txt')

with open('my_file.txt', 'r') as f:
    print ver_2(f)

Uno di questi è generalmente preferito? Si prevede generalmente che una funzione si comporterà in uno di questi due modi? O dovrebbe essere ben documentato in modo tale che il programmatore possa usare la funzione nel modo appropriato?

Le interfacce convenienti sono belle e talvolta la strada da percorrere. Tuttavia, il più delle volte una buona compostabilità è più importante della convenienza , in quanto un'astrazione componibile ci consente di implementare altre funzionalità (inclusi i wrapper per la convenienza).

Il modo più generale per la tua funzione di utilizzare i file è prendere un handle di file aperto come parametro, in quanto ciò consente di utilizzare anche handle di file che non fanno parte del filesystem (es. Pipe, socket, ...):

def your_function(open_file):
    return do_stuff(open_file)

Se l'ortografia with open(filename, 'r') as f: result = your_function(f)è troppo da chiedere ai tuoi utenti, puoi scegliere una delle seguenti soluzioni:

• your_functionaccetta un file aperto o un nome file come parametro. Se è un nome file, il file viene aperto e chiuso e le eccezioni vengono propagate. C'è un po 'di un problema con l'ambiguità qui che potrebbe essere aggirato usando argomenti denominati.

• Offri un semplice wrapper che si occupi dell'apertura del file, ad es

  def your_function_filename(file):
      with open(file, 'r') as f:
          return your_function(f)

  In genere percepisco funzioni come API bloat, ma se forniscono funzionalità di uso comune, la convenienza acquisita è un argomento sufficientemente forte.

• Avvolgi la with openfunzionalità in un'altra funzione componibile:

  def with_file(filename, callback):
      with open(filename, 'r') as f:
          return callback(f)

  usato come with_file(name, your_function)o in casi più complicatiwith_file(name, lambda f: some_function(1, 2, f, named=4))

La vera domanda è di completezza. La tua funzione di elaborazione dei file è l'elaborazione completa del file o è solo un pezzo in una catena di fasi di elaborazione? Se è completo e di per sé, sentiti libero di incapsulare tutto l'accesso ai file all'interno di una funzione.

def ver(filepath):
    with open(filepath, "r") as f:
        # do processing steps on f
        return result

Questa ha la proprietà molto bella di finalizzare la risorsa (chiusura del file) alla fine withdell'istruzione.

Se tuttavia è possibile che sia necessario elaborare un file già aperto, allora la distinzione tra te ver_1e ver_2ha più senso. Per esempio:

def _ver_file(f):
    # do processing steps on f
    return result

def ver(fileobj):
    if isinstance(fileobj, str):
        with open(fileobj, 'r') as f:
            return _ver_file(f)
    else:
        return _ver_file(fileobj)

Questo tipo di test esplicito del tipo è spesso disapprovato , specialmente in linguaggi come Java, Julia e Go in cui il dispacciamento basato sul tipo o sull'interfaccia è direttamente supportato. In Python, tuttavia, non esiste alcun supporto linguistico per il dispacciamento basato sul tipo. Di tanto in tanto potresti vedere critiche alla prova diretta del tipo in Python, ma in pratica è sia estremamente comune che abbastanza efficace. Permette a una funzione di avere un alto grado di generalità, gestendo qualsiasi tipo di dato sia probabile che arrivi, noto anche come "tipizzazione anatra". Nota il carattere di sottolineatura iniziale su _ver_file; questo è un modo convenzionale di designare una funzione (o metodo) "privata". Sebbene tecnicamente possa essere chiamato direttamente, suggerisce che la funzione non è destinata al consumo esterno diretto.

Aggiornamento 2019: dati i recenti aggiornamenti in Python 3, ad esempio che i percorsi sono ora potenzialmente archiviati come pathlib.Pathoggetti non solo stro bytes(3.4+) e che il tipo di suggerimento è passato dall'esoterico al mainstream (circa 3.6+, sebbene continui a evolversi attivamente), ecco codice aggiornato che tiene conto di questi progressi:

from pathlib import Path
from typing import IO, Any, AnyStr, Union

Pathish = Union[AnyStr, Path]  # in lieu of yet-unimplemented PEP 519
FileSpec = Union[IO, Pathish]

def _ver_file(f: IO) -> Any:
    "Process file f"
    ...
    return result

def ver(fileobj: FileSpec) -> Any:
    "Process file (or file path) f"
    if isinstance(fileobj, (str, bytes, Path)):
        with open(fileobj, 'r') as f:
            return _ver_file(f)
    else:
        return _ver_file(fileobj)

Se si passa il nome del file in giro anziché l'handle del file, non vi è alcuna garanzia che il secondo file sia lo stesso file del primo quando viene aperto; questo può portare a errori di correttezza e falle di sicurezza.

Si tratta della proprietà e della responsabilità di chiudere il file. Puoi passare un flusso o un handle di file o qualsiasi cosa che dovrebbe essere chiusa / disposta ad un certo punto a un altro metodo, a patto che tu sia sicuro di chi lo possiede e certo che verrà chiuso dal proprietario quando hai finito . Ciò implica in genere un costrutto try-finally o il modello usa e getta.

Se scegli di passare file aperti puoi fare qualcosa come il seguente MA NON hai accesso al nome file nella funzione che scrive nel file.

Lo farei se volessi avere una classe che era responsabile al 100% delle operazioni su file / stream e altre classi o funzioni che sarebbero state ingenue e che non si prevedeva di aprire o chiudere detti file / flussi.

Ricorda che i gestori di contesto funzionano come avere una clausola finally. Quindi, se viene generata un'eccezione nella funzione di scrittura, il file verrà chiuso in ogni caso.

import contextlib

class FileOpener:

    def __init__(self, path_to_file):
        self.path_to_file = path_to_file

    @contextlib.contextmanager
    def open_write(self):
        # ...
        # Here you can add code to create the directory that will accept the file.
        # ...
        # And you can add code that will check that the file does not exist 
        # already and maybe raise FileExistsError
        # ...
        try:            
            with open(self.path_to_file, "w") as file:
                print(f"open_write: has opened the file with id:{id(file)}")            
                yield file                
        except IOError:
            raise
        finally:
            # The try/catch/finally is not mandatory (except if you want to manage Exceptions in an other way, as file objects have predefined cleanup actions 
            # and when used with a 'with' ie. a context manager (not the decorator in this example) 
            # are closed even if an error occurs. Finally here is just used to demonstrate that the 
            # file was really closed.
            print(f"open_write: has closed the file with id:{id(file)} - {file.closed}")        


def writer(file_open, data, raise_exc):
    with file_open() as file:
        print("writer: started writing data.")
        file.write(data)
        if raise_exc:
            raise IOError("I am a broken data cable in your server!")
        print("writer: wrote data.")
    print("writer: finished.")

if __name__ == "__main__":
    fo = FileOpener('./my_test_file.txt')    
    data = "Hello!"  
    raise_exc = False  # change me to True and see that the file is closed even if an Exception is raised.
    writer(fo.open_write, data, raise_exc)