Beneficios de os.path.splitext sobre regular .split?

Question

En this other question, los votos muestran claramente que la función os.path.splitext es preferible a la simple manipulación de cadena .split('.')[-1]. ¿Alguien tiene un momento para explicar exactamente por qué es eso? ¿Es más rápido, o más preciso, o qué? Estoy dispuesto a aceptar que hay algo mejor al respecto, pero no puedo ver de inmediato qué podría ser. ¿Podría importar un módulo completo para hacer esto ser excesivo, al menos en casos simples?

EDITAR: La especificidad del sistema operativo es una gran ganancia que no es inmediatamente obvia; pero incluso yo debería haber visto el caso "¿Qué pasa si no hay un punto"? Y gracias a todos por los comentarios generales sobre el uso de la biblioteca.

Answer 1

Bueno, hay implementaciones separadas para sistemas operativos separados. Esto significa que si la lógica para extraer la extensión de un archivo difiere en Mac de la de Linux, esta distinción será manejada por esas cosas. No conozco ninguna distinción así que puede que no haya ninguna.

---

Editar: @Brian comentarios que un ejemplo como /directory.ext/file sería, por supuesto, no trabajar con un simple .split('.') llamada, y usted tendría que saber tanto que los directorios pueden utilizar extensiones, así como el hecho de que en algunas sistemas operativos, barra diagonal es un separador de directorio válido.

Esto solo enfatiza que el usa una rutina de biblioteca a menos que tenga una buena razón para no incluir parte de mi respuesta.

Gracias @Brian.

---

Además, cuando un archivo no tiene una extensión, debe crear lógica para manejar ese caso. ¿Y qué sucede si lo que intentas dividir es un nombre de directorio que termina con una barra diagonal inversa? Sin nombre de archivo ni extensión

La regla debería ser que a menos que tenga una razón específica para no usar una función de biblioteca que haga lo que desee, úselo. Esto evitará tener que mantener y corregir códigos que otros tienen soluciones perfectamente buenas.

Answer 2

En el comentario a la respuesta que proporciona esta solución:

"Si el archivo no tiene extensión Esto devuelve incorrectamente el nombre de archivo en lugar de una cadena vacía."

No todos los archivos tienen una extensión.

Answer 3

Un método claramente definido y documentado para obtener la extensión de archivo siempre sería preferible a la división de una cadena de cualquier manera, ya que ese método sería más frágil por varias razones.

Editar: Esto no es específico del idioma.

Answer 4

os.path.splitext manejará correctamente la situación donde el archivo no tiene extensión y devolverá una cadena vacía. .split devolverá el nombre del archivo.

Answer 5

La primera y más obvia diferencia es que la llamada dividida no tiene lógica predeterminada cuando no hay extensión.

Esto también se puede lograr con una expresión regular, para que se comporte como un 1 liner sin inclusiones adicionales, pero igual devuelva, cadena vacía si la extensión no está allí.

Además, la biblioteca de rutas puede manejar contextos diferentes para rutas que tienen diferentes separadores para carpetas.

Answer 6

Existen sistemas operativos que no usan '.' Como separador de extensiones.

(Notablemente, RISC OS, por convención, utiliza '/', ya que '' se utiliza allí como un separador de ruta.)

Answer 7

1. herramienta adecuada para el trabajo correcto
2. Ya bien depurado y probado como parte de la biblioteca estándar de Python: no hay errores introducidos por errores en la versión enrollada a mano (por ejemplo, ¿qué pasa si no hay extensión, o el archivo es un archivo oculto en UNIX como '.bashrc', o hay varias extensiones?)
3. Al estar diseñado para este propósito, la función tiene valores de retorno útiles (nombre base, ext) para el nombre de archivo pasado, que puede ser más útil en ciertos casos frente a tener que dividir la ruta manualmente (de nuevo, casos extremos podrían ser una preocupación cuando averiguar el nombre base - ext)

La única razón por la que preocuparse acerca de la importación del módulo es la preocupación por encima de la cabeza - que no es probable que ser una preocupación en la gran mayoría de los casos, y si es así de apretada, entonces es probable que otros gastos generales en Python supongan un problema mayor antes de eso.

Answer 8

splitext() hace una búsqueda inversa para '.' y devuelve la porción de extensión tan pronto como la encuentre. split('.') hará una búsqueda directa para todos '.' personajes y, por lo tanto, casi siempre es más lento. En otras palabras, splitext() está específicamente escrito para devolver la extensión a diferencia de split().

(consulte posixpath.py en la fuente de Python si desea examinar la implementación).

Answer 9

Además de ser estándar y, por tanto, garantiza que sea disponible, os.path.splitext:

maneja los casos de borde - como la de una extensión que falta.
Ofrece garantías - Además de devolver correctamente la extensión, si existe, garantiza que root + ext siempre devolverá la ruta completa.
Es multiplataforma - en la fuente de Python, en realidad hay tres versiones diferentes de os.path, y se llaman en función del sistema operativo en el que Python cree que se encuentra.
Es más legible - tenga en cuenta que su versión requiere que los usuarios sepan que los arreglos se pueden indexar con números negativos.

por cierto, no debería ser más rápido.

Answer 10

1) simple split ('.') [- 1] no funcionará correctamente para la ruta como C: \ foo.bar \ Makefile, por lo que primero debe extraer basename con os.path.basename(), e incluso en este caso no podrá dividir el archivo sin extensión correctamente. os.path.splitext haz esto debajo del capó.

2) A pesar de que os.path.splitext es una solución multiplataforma, no es ideal.Veamos los archivos especiales con punto inicial, p. .cvsignore, .bzrignore, .hgignore (son muy populares en algunos VCS como archivos especiales). os.path.splitext devolverá el nombre completo del archivo como extensión, aunque no me parece correcto. Porque en este caso, el nombre sin extensión es una cadena vacía. Aunque este es el comportamiento previsto de la biblioteca estándar de Python, es posible que no sea lo que realmente quiere el usuario.

Answer 11

no estoy seguro de Python ha sido portado a la plataforma VMS, pero suponiendo que lo hicieron (*):

• Los nombres de archivo son típicamente del formato:. $ Dispositivo-dir-subdirectorio $ Nombre Tipo $; $ versión (**)

espero que te das cuenta de que el uso de un método de alcance restringido, que sólo se ve influenciada por los sistemas que está expuesto en adelante, no es óptimo para el mantenimiento de código largo plazo y tal las prácticas son particularmente perjudiciales para mezclar y combinar componentes de software dispares en proyectos de software más grandes s.

Esencialmente, en este último caso la probabilidad de éxito (fiabilidad) es similar a

R (t) = 1- (1-Ri)^n

y ahora se puede ver cómo las implementaciones de software pobres/incompletas resultan en programas defectuosos. En términos más generales, el software de portabilidad es difícil precisamente debido a dichos errores.

(*) hm, Google reveló rápidamente alrededor de: https://www.vmspython.org
(**) ¡Consulte las guerras de regex aquí! https://stackoverflow.com/a/4465456/1574494