¿Debo pasar los nombres de archivo para abrir, o abrir archivos?

Las interfaces convenientes son agradables y, a veces, el camino a seguir. Sin embargo, la mayoría de las veces, una buena capacidad de es más importante que la conveniencia , ya que una abstracción composable nos permite implementar otras funcionalidades (incluidos los envoltorios de conveniencia) que están encima.

La forma más general para que su función use archivos es tomar un identificador de archivo abierto como parámetro, ya que esto le permite usar también identificadores de archivo que no forman parte del sistema de archivos (por ejemplo, tuberías, enchufes, ...):

def your_function(open_file):
    return do_stuff(open_file)

Si deletrear with open(filename, 'r') as f: result = your_function(f) es mucho pedir a sus usuarios, puede elegir una de las siguientes soluciones:

• your_function toma un archivo abierto o un nombre de archivo como parámetro. Si es un nombre de archivo, el archivo se abre y se cierra, y se propagan las excepciones. Existe un pequeño problema con la ambigüedad que podría solucionarse mediante el uso de argumentos con nombre.

• Ofrezca un envoltorio sencillo que se encargue de abrir el archivo, por ejemplo,

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

  Por lo general, percibo funciones como el aumento de API, pero si proporcionan una funcionalidad de uso común, la conveniencia obtenida es un argumento suficientemente sólido.

• Envuelva la funcionalidad with open en otra función composible:

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

  utilizado como with_file(name, your_function) o en casos más complicados with_file(name, lambda f: some_function(1, 2, f, named=4))

La verdadera pregunta es de integridad. ¿Es su función de procesamiento de archivos el procesamiento completo del archivo, o es solo una pieza en una cadena de pasos de procesamiento? Si está completo en sí mismo, entonces siéntase libre de encapsular todo el acceso a los archivos dentro de una función.

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

Esto tiene la muy buena propiedad de finalizar el recurso (cerrar el archivo) al final de la declaración with .

Si, sin embargo, es posible que sea necesario procesar un archivo ya abierto, entonces la distinción entre ver_1 y ver_2 tiene más sentido. Por ejemplo:

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)

Este tipo de pruebas de tipo explícitas a menudo son mal vistas , especialmente en lenguajes como Java, Julia y Go, donde se admite directamente el envío basado en tipo o interfaz. En Python, sin embargo, no hay soporte de idioma para el envío basado en tipos. Es posible que ocasionalmente veas críticas de pruebas de tipo directas en Python, pero en la práctica es extremadamente común y bastante efectivo. Permite que una función tenga un alto grado de generalidad, manejando cualquier tipo de datos que probablemente se presente, también conocido como "tipificación de pato". Tenga en cuenta el guión bajo en _ver_file ; esa es una forma convencional de designar una función (o método) "privada". Si bien técnicamente se puede llamar directamente, sugiere que la función no está destinada al consumo externo directo.

Si pasa el nombre del archivo en lugar del identificador del archivo, no hay garantía de que el segundo archivo sea el mismo que el primero cuando se abre; Esto puede llevar a errores de corrección y agujeros de seguridad.