{"id":234,"date":"2020-11-29T23:16:43","date_gmt":"2020-11-30T04:16:43","guid":{"rendered":"https:\/\/www.alpharithms.com\/?p=234"},"modified":"2022-06-16T15:23:58","modified_gmt":"2022-06-16T19:23:58","slug":"how-to-get-a-filename-from-a-path-in-python","status":"publish","type":"post","link":"https:\/\/www.alpharithms.com\/how-to-get-a-filename-from-a-path-in-python-431623\/","title":{"rendered":"How To Get a Filename From a Path in Python"},"content":{"rendered":"

Extracting a filename from a path in python is simple and can be achieved using only the standard library. However, there are some quirks that one needs to be aware of to ensure predictable functionality as well as cross-platform interoperability.<\/p>\n

Python’s os module provides a laundry list of functions to help handle paths. The os.path.basename and os.path.split<\/code> functions both come in particularly good use when approaching such a task.<\/p>\n

However, these functions don’t always behave the same on Windows and Linux machines. Let’s consider some common cases and where troubles might pop up.<\/p>\n

OS Module: Common Uses+ Common Issues<\/h2>\n

Python’s os<\/code> module contains many useful path-related tools and supports cross-platform use. As noted in the os modules documentation:<\/p>\n

Programs that import and use ‘os’ stand a better chance of being portable between different platforms.<\/em><\/p>\n

Among the many useful path tools in the os<\/code> module are the os.path.basename<\/code> and os.path.split<\/code> functions. Each of these can return the filename from a path in Python but fail somewhat unexpectedly in some cases. In the following examples, these two functions find the filename easily:<\/p>\n

import os\r\n\r\n# Define a test file\r\nFILE = \"C:\/path\/to\/my\/file.ext\"\r\n\r\n# Print example filename outputs\r\nprint(os.path.basename(FILE))\r\nprint(os.path.split(FILE))\r\n\r\n# Output\r\n>>> file.ext\r\n>>> ('C:\/path\/to\/my', 'file.ext')<\/pre>\n
Note that the os.path.split<\/code> function returns a tuple as the (head, tail) of the path. For direct filename extraction, you would want to capture just the tail portion by either indexing into the return value as such: os.path.split(FILE)[1]<\/code> or by unpacking the values into variables like so head, tail = os.path.split(FILE)<\/code>.<\/p>\n
Trailing Slash Issues<\/h3>\n
The first area where this approach fails is when a file path ends with a trailing slash (forward, back, double or single). Consider the code from above again, but this time with a trailing slash on the filepath string:<\/p>\n
# Define a test file\r\nFILE = \"C:\/path\/to\/my\/file.ext\/\"  # <--note the trailing slash\r\n\r\n# Print example filename outputs\r\nprint(os.path.basename(FILE))\r\nprint(os.path.split(FILE))\r\n\r\n# Output\r\n>>> \r\n>>> ('C:\/path\/to\/my\/file.ext', '')<\/pre>\n
In the case of the first approach; os.path.basename(FILE)<\/code> the return value is blank<\/strong>.\u00a0 Trailing slashes produce empty filename values using the os<\/code> module. This output is produced on both Linux and Windows<\/strong> machines. This happens for both single and<\/em> double (escaped) slash values. This is the first hiccup in using the os module but there are also some issues when moving between platforms.<\/p>\n
Linux Issue with Windows-Formatted Paths<\/h3>\n
The code above also will fail on a Linux machine trying to process a Windows-formatted path. For example, the command os.path.basename(\"C:\\\\path\\\\to\\\\my\\file.ext\")<\/code> will produce the following output: \"C:\\\\path\\\\to\\\\my\\file.ext\"<\/code> .<\/p>\n
Similarly, using the os.path.split(\"C:\\\\path\\\\to\\\\my\\\\file.ext\")<\/code> command will result in the following unwanted output: ('', 'C:\\\\path\\\\to\\\\my\\\\file.ext')<\/code> where the first tuple value (the head<\/em>) is the empty string and the second value (the tail<\/em>) is the full file path rather than the filename.<\/p>\n
ntpath Module: Cross-Platform Fallback<\/h2>\n
Under the hood of the os<\/code> module, one will find that it actually imports ntpath<\/code> to handle path<\/code> functions on Windows machines. This can be observed by the following lines of code from the os module:<\/p>\n
elif 'nt' in _names:\r\n    name = 'nt'\r\n    linesep = '\\r\\n'\r\n    from nt import *\r\n    try:\r\n        from nt import _exit\r\n        __all__.append('_exit')\r\n    except ImportError:\r\n        pass\r\n    import ntpath as path\r\n\r\n    import nt\r\n    __all__.extend(_get_exports_list(nt))\r\n    del nt\r\n\r\n    try:\r\n        from nt import _have_functions\r\n    except ImportError:\r\n        pass<\/pre>\n
The import nt as path<\/code> is the line is most relevant to the discussion here. This instructs python to import the ntpath<\/code> module as the os.path<\/code> on Windows machines. Essentially, whether you import ntpath<\/code> or os.path<\/code> you’ll be getting the same functionality on a Windows machine.<\/p>\n
Note<\/strong>: ntpath<\/code> treats both \/<\/code> and \\<\/code> as directory separators<\/p>\n
What happens on a Linux machine though? Let’s look at the source code for the os<\/code> module once again, this time just above the prior code:<\/p>\n
if 'posix' in _names:\r\n    name = 'posix'\r\n    linesep = '\\n'\r\n    from posix import *\r\n    try:\r\n        from posix import _exit\r\n        __all__.append('_exit')\r\n    except ImportError:\r\n        pass\r\n    import posixpath as path\r\n\r\n    try:\r\n        from posix import _have_functions\r\n    except ImportError:\r\n        pass\r\n\r\n    import posix\r\n    __all__.extend(_get_exports_list(posix))\r\n    del posix<\/pre>\n
The import posixpath as path<\/code> is the line of interest here if, for no other reason, than to demonstrate that python’s os.path<\/code> module operates differently between Linux and Windows machines.<\/p>\n
Armed with that knowledge, the goal now becomes that of creating a solution to produce the desired result on both platforms\u2014handling Windows-formatted paths on Linux\u00a0and<\/em> dealing with trailing slashes.<\/p>\n
Custom ntpath Function to Extract Filename<\/h2>\n
Importing the ntpath<\/code> module explicitly seems the best approach to offering unified functionality between Windows and Linux machines. However, it’s unclear as to the best approach for dealing with the trailing slashes. Consider the following code:<\/p>\n
import ntpath\r\n\r\n# Test path\r\nFILE = \"C:\\\\path\\\\to\\\\my\\\\file\\\\\"\r\n\r\n# print examples from filepath\r\nntpath.split(FILE)\r\nntpath.basename(FILE)\r\n\r\n# Returned Values (same on windows and linux)\r\n>>> ('C:\\\\path\\\\to\\\\my\\\\file', '')\r\n>>> ''<\/pre>\n
These results are identical on both Windows and Linux machines, but still produce unwanted results. However, it gets us one step closer to a unified solution.<\/p>\n
Notice the return value of the ntpath.os.split<\/code> function returns the file path without<\/em> the trailing slash as part of its tuple. Using this allows for the creation of a custom function with a simple conditional to handle all cases with ease:<\/p>\n
import ntpath\r\n\r\n\r\ndef extract_filename(filepath: str) -> str:\r\n    \"\"\"\r\n    Given a filepath string, extract the filename regardless of file separator type\r\n    or presence in the trailing position.\r\n    Args:\r\n        filepath: the filepath string from which to extract the filename\r\n    Returns:\r\n        str object representing the file\r\n    \"\"\"\r\n    head, tail = ntpath.split(filepath)\r\n    return tail or ntpath.basename(head)\r\n\r\n# Test paths\r\nPATHS = [\r\n    \"\/path\/to\/my\/filename\",\r\n    \"\/path\/to\/my\/filename\/\",\r\n    \"path\/to\/my\/filename\",\r\n    \"path\/to\/my\/filename\/\"\r\n    \"\\\\path\\\\to\\\\my\\\\filename\",\r\n    \"\\\\path\\\\to\\\\my\\\\filename\\\\\",\r\n    \"path\\\\to\\\\my\\\\filename\",\r\n    \"path\\\\to\\\\my\\\\filename\\\\\"\r\n]\r\n\r\n# Get filename for all paths\r\nprint([extract_filename(p) for p in PATHS])\r\n\r\n# Produces the following output\r\n>>> ['filename', 'filename', 'filename', 'filename', 'filename', 'filename', 'filename']<\/pre>\n
This approach handles both forward and backslashes, handles file paths with trailing slashes, and<\/em> produces the same output on both Windows and Linux machines. For those interested, this code is available on GitHub<\/a>.<\/p>\n
Discussion<\/h2>\n
Python is one of my favorite languages to handle file paths with. It has several tools built-in to the standard libraries that greatly simplify creating path variables for common system paths, project paths, and system files.<\/p>\n
As illustrated above, python makes it easy to get a filename from a path, provided you are ready to handle some quirks.<\/p>\n
Cross-platform compatibility becomes an issue when dealing with Windows-formatted double backslashing file paths\u2014Linux machines don’t handle those well. However, falling back on the ntpath<\/code> module and using a little bit of conditional logic can solve all such problems.<\/p>\n","protected":false},"excerpt":{"rendered":"
Extracting a filename from a path in python is simple and can be achieved using only the standard library. However, there are some quirks that one needs to be aware of to ensure predictable functionality as well as cross-platform interoperability. Python’s os module provides a laundry list of functions to help handle paths. The os.path.basename […]<\/p>\n","protected":false},"author":2,"featured_media":307,"comment_status":"closed","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"_acf_changed":false,"inline_featured_image":false,"footnotes":""},"categories":[655,10],"tags":[139,14,141,138,143,142,140,144],"acf":[],"_links":{"self":[{"href":"https:\/\/www.alpharithms.com\/wp-json\/wp\/v2\/posts\/234"}],"collection":[{"href":"https:\/\/www.alpharithms.com\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.alpharithms.com\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.alpharithms.com\/wp-json\/wp\/v2\/users\/2"}],"replies":[{"embeddable":true,"href":"https:\/\/www.alpharithms.com\/wp-json\/wp\/v2\/comments?post=234"}],"version-history":[{"count":8,"href":"https:\/\/www.alpharithms.com\/wp-json\/wp\/v2\/posts\/234\/revisions"}],"predecessor-version":[{"id":311,"href":"https:\/\/www.alpharithms.com\/wp-json\/wp\/v2\/posts\/234\/revisions\/311"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/www.alpharithms.com\/wp-json\/wp\/v2\/media\/307"}],"wp:attachment":[{"href":"https:\/\/www.alpharithms.com\/wp-json\/wp\/v2\/media?parent=234"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.alpharithms.com\/wp-json\/wp\/v2\/categories?post=234"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.alpharithms.com\/wp-json\/wp\/v2\/tags?post=234"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}