Controlla se l'oggetto è simile a un file in Python

Gli oggetti simili a file sono oggetti in Python che si comportano come un file reale, ad esempio hanno un metodo read () e un metodo di scrittura (), ma hanno un'implementazione diversa. È la realizzazione del concetto di Duck Typing .

È considerata una buona pratica consentire un oggetto simile a un file ovunque sia previsto un file in modo che, ad esempio, un oggetto StringIO o Socket possa essere utilizzato al posto di un file reale. Quindi è brutto eseguire un controllo come questo:

if not isinstance(fp, file):
   raise something

Qual è il modo migliore per verificare se un oggetto (ad esempio un parametro di un metodo) è "simile a un file"?

Generalmente non è buona norma avere controlli come questo nel codice a meno che non si abbiano requisiti speciali.

In Python la digitazione è dinamica, perché senti il ​​bisogno di controllare se l'oggetto è simile a un file, invece di usarlo come se fosse un file e gestire l'errore risultante?

Qualsiasi controllo che puoi fare avverrà comunque in fase di esecuzione, quindi fare qualcosa di simile if not hasattr(fp, 'read')e sollevare qualche eccezione fornisce un po 'più di utilità rispetto alla semplice chiamata fp.read()e gestione dell'errore di attributo risultante se il metodo non esiste.

Per 3.1+, uno dei seguenti:

isinstance(something, io.TextIOBase)
isinstance(something, io.BufferedIOBase)
isinstance(something, io.RawIOBase)
isinstance(something, io.IOBase)

Per 2.x, "un oggetto simile a un file" è una cosa troppo vaga da controllare, ma la documentazione per qualsiasi funzione con cui hai a che fare, si spera, ti dirà di cosa hanno effettivamente bisogno; in caso contrario, leggi il codice.

Come sottolineano altre risposte, la prima cosa da chiedere è cosa stai controllando esattamente. Di solito, EAFP è sufficiente e più idiomatico.

Il glossario dice "file come oggetto" è sinonimo di "oggetto file", che in ultima analisi significa che è un esempio di una delle tre classi base astratte definite nel il iomodulo , che sono essi stessi tutte le sottoclassi di IOBase. Quindi, il modo per controllare è esattamente come mostrato sopra.

(Tuttavia, il controllo IOBasenon è molto utile. Riuscite a immaginare un caso in cui è necessario distinguere un effettivo file-like read(size)da una funzione con un argomento chiamata readche non è file-like, senza dover distinguere anche tra file di testo e raw file binari? Quindi, in realtà, vuoi quasi sempre controllare, ad esempio, "è un oggetto file di testo", non "è un oggetto simile a file".)

Per 2.x, mentre il iomodulo esiste dalla 2.6+, gli oggetti file incorporati non sono istanze di ioclassi, né lo sono nessuno degli oggetti simili a file nello stdlib, e nemmeno la maggior parte degli oggetti file di terze parti è probabile che tu incontri. Non esisteva una definizione ufficiale di cosa significhi "oggetto simile a file"; è solo "qualcosa come un oggetto file incorporato ", e funzioni diverse significano cose diverse con "mi piace". Tali funzioni dovrebbero documentare cosa significano; se non lo fanno, devi guardare il codice.

Tuttavia, i significati più comuni sono "ha read(size)", "ha read()" o "è un iterabile di stringhe", ma alcune vecchie librerie potrebbero aspettarsi readlineinvece di uno di questi, ad alcune librerie piacciono i close()file che gli dai, alcuni si aspetteranno che se filenoè presente, quindi sono disponibili altre funzionalità, ecc. E allo stesso modo per write(buf)(sebbene ci siano molte meno opzioni in quella direzione).

Come altri hanno già detto, in genere dovresti evitare tali controlli. Un'eccezione è quando l'oggetto potrebbe essere legittimamente di tipo diverso e si desidera un comportamento diverso a seconda del tipo. Il metodo EAFP non funziona sempre qui poiché un oggetto potrebbe assomigliare a più di un tipo di anatra!

Ad esempio, un inizializzatore potrebbe prendere un file, una stringa o un'istanza della propria classe. Potresti quindi avere un codice come:

class A(object):
    def __init__(self, f):
        if isinstance(f, A):
            # Just make a copy.
        elif isinstance(f, file):
            # initialise from the file
        else:
            # treat f as a string

L'uso di EAFP qui potrebbe causare tutti i tipi di problemi sottili poiché ogni percorso di inizializzazione viene eseguito parzialmente prima di lanciare un'eccezione. Essenzialmente questa costruzione imita il sovraccarico della funzione e quindi non è molto pitonica, ma può essere utile se usata con cura.

Come nota a margine, non puoi eseguire il controllo dei file allo stesso modo in Python 3. Avrai invece bisogno di qualcosa di simile isinstance(f, io.IOBase).

Il paradigma dominante qui è EAFP: è più facile chiedere perdono che permesso. Vai avanti e utilizza l'interfaccia del file, quindi gestisci l'eccezione risultante o lascia che si propagino al chiamante.

È spesso utile sollevare un errore controllando una condizione, quando normalmente l'errore non verrebbe generato fino a molto tempo dopo. Ciò è particolarmente vero per il confine tra codice "user-land" e "api".

Non metteresti un metal detector in una stazione di polizia sulla porta di uscita, lo metteresti all'ingresso! Se non controllare una condizione significa che potrebbe verificarsi un errore che potrebbe essere stato rilevato 100 righe prima, o in una superclasse invece di essere sollevato nella sottoclasse, allora dico che non c'è niente di sbagliato nel controllo.

Controllare i tipi corretti ha senso anche quando accetti più di un tipo. È meglio sollevare un'eccezione che dice "Richiedo una sottoclasse di stringa di base, OR file" piuttosto che sollevare semplicemente un'eccezione perché alcune variabili non hanno un metodo 'seek' ...

Questo non significa che impazzisci e lo fai ovunque, per la maggior parte sono d'accordo con il concetto di eccezioni che si sollevano da sole, ma se puoi rendere la tua API drasticamente chiara o evitare l'esecuzione di codice non necessaria perché una semplice condizione non è stata soddisfatta fare così!

Puoi provare a chiamare il metodo quindi catturare l'eccezione:

try:
    fp.read()
except AttributeError:
    raise something

Se vuoi solo un metodo di lettura e scrittura puoi farlo:

if not (hasattr(fp, 'read') and hasattr(fp, 'write')):
   raise something

Se fossi in te sceglierei il metodo try / tranne.

Nella maggior parte dei casi, il modo migliore per gestire questo problema è non farlo. Se un metodo accetta un oggetto simile a un file e risulta che l'oggetto che è passato non lo è, l'eccezione che viene sollevata quando il metodo tenta di utilizzare l'oggetto non è meno informativa di qualsiasi eccezione che potresti aver sollevato esplicitamente.

C'è almeno un caso in cui potresti voler fare questo tipo di controllo, però, ed è quando l'oggetto non viene utilizzato immediatamente da ciò a cui lo hai passato, ad esempio se è impostato nel costruttore di una classe. In tal caso, penso che il principio dell'EAFP sia superato dal principio del "fail fast". Controllerei l'oggetto per assicurarmi che implementasse i metodi di cui la mia classe ha bisogno (e che siano metodi), ad esempio:

class C():
    def __init__(self, file):
        if type(getattr(file, 'read')) != type(self.__init__):
            raise AttributeError
        self.file = file

Mi sono imbattuto nella tua domanda mentre stavo scrivendo una openfunzione simile a quella che poteva accettare un nome file, un descrittore di file o un oggetto simile a un file pre-aperto.

Invece di provare un readmetodo, come suggeriscono le altre risposte, ho finito per controllare se l'oggetto può essere aperto. Se possibile, è una stringa o un descrittore e ho in mano un oggetto simile a un file valido dal risultato. Se opensolleva a TypeError, l'oggetto è già un file.