pathlib: Filenames consisting only of an extension (".txt", ".png") are treated as having no suffix

[tokitoki22]

Bug report

Bug description:

Summary

pathlib.Path treats filenames that consist only of a dot-prefixed extension such as .txt, .png, .jpeg, etc. as files with no suffix, and assigns the entire string to .stem.

This behavior is surprising and inconsistent with common filesystem interpretations, where such names are generally understood as files with an extension and an empty basename.

Examples

from pathlib import Path

p = Path(".txt")

p.stem      # ".txt"
p.suffix    # ""        <-- unexpected
p.suffixes  # []        <-- unexpected

---

Expected Behavior

For a filename representing “extension-only” files:

• .txt → stem = "", suffix = ".txt"
• .png → stem = "", suffix = ".png"

This would align with:

• how most operating systems treat these names
• how editors, file explorers, MIME resolvers interpret them
• the intuitive model that "suffix = extension"

---

Actual Behavior

pathlib interprets .txt as:

• basename = .txt
• extension = none

This leads to operations like:

Path(".png").with_stem("123")   # → "123"   (loses .png)

behaving inconsistently, and breaks workflows that expect deterministic suffix logic.

---

Why This Matters

pathlib is often used specifically to avoid manual string parsing. However, its current handling of extension-only filenames creates surprising situations when writing tools such as:

• batch image / asset processors
• file renamers
• templated filename builders
• any system relying on predictable suffix logic

This behavior is especially problematic on Windows, where .txt, .png, .ini are widely recognized as “files with an extension”.

---

Related Issues (Not duplicates)

I reviewed the following issues before submitting:

• pathlib .suffix, .suffixes, .stem unexpected behavior for pathname with trailing dot #82805 – behavior for filenames ending with a trailing dot ("file.")
• Suffix in pathlib is not behaving like a file extension #121347 – inconsistent suffix extraction with unusual patterns

These are related in spirit (edge cases in suffix/stem parsing), but do not cover the case where the entire filename is just an extension-like string such as:

• .txt
• .png
• .jpeg

These are interpreted as “no suffix” and .stem == filename,
therefore this is not a duplicate.

---

Versions Tested

I have reproduced this behavior on:

• Python 3.11
• Python 3.12

I could not find any indication in the changelogs or issue tracker that this behavior has been changed in newer versions (3.13+). If this has already been addressed, a pointer would be appreciated.

---

Suggested Direction

I am not proposing an immediate breaking change, but raising the question:

Should extension-only filenames be handled in a more intuitive and consistent way,
aligning .suffix with OS / filetool expectations?

Possible directions include:

• treating .txt like a normal extension
• or at minimum documenting this edge case more clearly

---

Thank you

I appreciate the work that goes into pathlib, and I hope this issue helps improve the clarity and consistency of filename handling.

CPython versions tested on:

3.12

Operating systems tested on:

Windows

[sergey-miryanov]

Closing as LLM-generated.

[tokitoki22]

This issue is based on my own testing and the behavior I observed directly in Python 3.11 and 3.12 to make comfy ui custom nodes.

The text was edited for clarity, but the problem description, examples, and expected behavior are my own work and reproduction.

The behavior of Path(".txt").suffix == "" is still reproducible, and the issue is not present in any existing tickets except partially related ones I reviewed (#82805, #121347).

Could this be reopened for technical evaluation rather than being closed as LLM-generated?

[tokitoki22]

There is no logical reason to reject a bug report that is formatted, translated, and submitted by someone whose native language is not English. If LLM can produce more logical and polite reports, I thought it was only natural to use it. Not only is it a matter of not using it personally, but rejecting someone else's report, It will have no positive impact on the community as a whole.

[sergey-miryanov]

I suggest you open a discussion at https://discuss.python.org/c/ideas/6.
If your proposal gets some valuable support from community feel free to reopen this issue.

[tokitoki22]

I suggest you open a discussion at https://discuss.python.org/c/ideas/6. If your proposal gets some valuable support from community feel free to reopen this issue.

I feel that closing my issue as “LLM-generated” and marking it as invalid, without evaluating its technical content or providing any substantive explanation, was not appropriate and was not respectful for a contributor discussion.Given this interaction, it seems more appropriate for me to report your handling of the issue to the moderation team.

Then I will open a new issue written in my own words as suggestion, because the technical problem still exists.,I do not need further advice from you regarding this matter.

[Eclips4]

@tokitoki22 Hi!
These days CPython is getting a lot of LLM-generated issues, PRs, and comments, and this one really looks like LLM-generated (as you’ve confirmed). We encourage using LLMs for communication, especially since many of us aren’t native English speakers (I sometimes use one myself to fix my grammar 🙂).
Your issue is technically correct, but please use LLMs only for translation or grammar help. I’m reopening it, but please rephrase it to sound more "natural and human". Thank you!