Benefits of os.path.splitext over regular .split?

前端 未结 11 928
独厮守ぢ
独厮守ぢ 2020-12-08 13:16

In this other question, the votes clearly show that the os.path.splitext function is preferred over the simple .split(\'.\')[-1] string manipulatio

相关标签:
11条回答
  • 2020-12-08 14:00

    Well, there are separate implementations for separate operating systems. This means that if the logic to extract the extension of a file differs on Mac from that on Linux, this distinction will be handled by those things. I don't know of any such distinction so there might be none.


    Edit: @Brian comments that an example like /directory.ext/file would of course not work with a simple .split('.') call, and you would have to know both that directories can use extensions, as well as the fact that on some operating systems, forward slash is a valid directory separator.

    This just emphasizes the use a library routine unless you have a good reason not to part of my answer.

    Thanks @Brian.


    Additionally, where a file doesn't have an extension, you would have to build in logic to handle that case. And what if the thing you try to split is a directory name ending with a backslash? No filename nor an extension.

    The rule should be that unless you have a specific reason not to use a library function that does what you want, use it. This will avoid you having to maintain and bugfix code others have perfectly good solutions to.

    0 讨论(0)
  • 2020-12-08 14:01

    In the comment to the answer that provided this solution:

    "If the file has no extension this incorrectly returns the file name instead of an empty string."

    Not every file has an extension.

    0 讨论(0)
  • 2020-12-08 14:05
    1. Right tool for the right job
    2. Already thoroughly debugged and tested as part of the Python standard library - no bugs introduced by mistakes in your hand-rolled version (e.g. what if there is no extension, or the file is a hidden file on UNIX like '.bashrc', or there are multiple extensions?)
    3. Being designed for this purpose, the function has useful return values (basename, ext) for the filename passed, which can be more useful in certain cases versus having to split the path manually (again, edge cases could be a concern when figuring out the basename - ext)

    The only reason to worry about importing the module is concern for overhead - that's not likely to be a concern in the vast majority of cases, and if it is that tight then it's likely other overhead in Python will be a bigger problem before that.

    0 讨论(0)
  • 2020-12-08 14:05

    I am not sure Python has been ported on the VMS platform, but assuming it did (*):

    • Filenames are typically of the format: $device-dir-subdir$filename.$type;$version (**)

    I hope you realize that using a narrow-scope method, which is only influenced by the systems you are exposed on, isn't optimal for long-term code maintainability and such practices are particularly detrimental to mixing and matching disparate software components in larger software projects.

    Essentially, in the latter case the success probability (dependability) is akin to

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

    and you can now see how poor/incomplete software implementations result into buggy programs. More broadly speaking, porting software is difficult precisely due to such bugs.

    (*) hm, googling revealed quickly about: https://www.vmspython.org
    (**) Check at the regex wars over here! https://stackoverflow.com/a/4465456/1574494

    0 讨论(0)
  • 2020-12-08 14:08

    os.path.splitext will correctly handle the situation where the file has no extension and return an empty string. .split will return the name of the file.

    0 讨论(0)
提交回复
热议问题