Path(".png").stem should return "" and not file extension like".png"

[tokitoki22]

Feature or enhancement

Proposal:

I am using " translation tool" to write this post, but the content itself is not machine-generated. Everything described here is based on my actual experience, testing, and verification in Python just to make custom nodes for comfy-ui . I reported this issue as pathlib bug, but one contributor set the post as "invalid "and "not thinking"because I use LLM to format report and transltate,

but the reason "I use LLM" was simply make report precise and clear. Then Now I report again as "suggesition".

When a filename like ".png" or ".txt" is passed to a Path object and I use fp.stem or try to rename the file using fp.with_stem(), I believe the returned values should follow what the documentation describes. Currently the behavior is inconsistent for extension-only filenames.

This is actual code segment, (for custom node to save file with free prefix suffix, mix use preset json path names, for comfy-ui

fp = Path(file_name)
f_stem = pre_exp + fp.stem + suf_exp
save_file = fp.with_stem(f_stem)

In this custom save txt/image node, user can set "prefix" , "suffix" with file name, and dir path. there are case, user may only hope to set file name as ".png" or ".txt" , but use prefix to batch generation.
(set seed int values as string list prefix , or set Time, date as string suffix , with empty filename input, but "file identifier" like ".png" , ".jpeg" etc.

python pathlib document
pathlib.stem
"The final path component, without its suffix"

so, If {file_name} is ".png" or ".txt" , I expect fp.stem should return "", then
f_stem >> pre_exp + suf_exp

finally, fp will change user input "file name" by new stems(eg "298562", but keep their file type. (.txt or .png) ,
by using with_stem()

But actual behavor was
fp = Path(".png")
fp >> WindowsPath('.png')

fp.stem >> ".png" (it is not "stem" but it return file identifier, or suffix)
fp.with_stem("11539") >> "11539" (it remove the identiifer ".png" and convert it with stem.

Has this already been discussed elsewhere?

I have already discussed this feature proposal on Discourse

Links to previous discussion of this feature:

#142005 (comment)
btw now my report seems open again, thanks.

[sobolevn]

'.png' is not a file extension, it is a file's name. 'file.jpg' has a file extension of '.jpg'. If you use other filename like '.config' or '.env' it would be more obvious.

We have an explicit test that this is the correct and expected behavior:

cpython/Lib/test/test_pathlib/test_join.py

Line 316 in d5d9e89

self.assertEqual(P('a/.hgrc').stem, '.hgrc')

[tokitoki22]

Actually it seems simply your or yours policy how use "word" about letter, strings .even htough there is no clear reason why you should think so.

I know, there is no real file like ".png" or ".txt" , but it never means ".txt " or ".jpeg" or ".md" should represent as file name. Most of user may prefer to think them as letter to decide "file type" rather than pretend and insist "These are file name"

Many windows editor or aprication which manage and save files, you may see many "file-type" category, they are separated and represet as ".png" ".txt" ".py". Yes we choose them as file-type. never choose or select them as file name. even though we set file-stem as empty.

you may see "check box" to add "file-type". eg ".py" Actually many user recgonize ".png" or ".md" or ".config" as " file extension. " not think they are file-name.

of course we use them as "part of file name" but if you see, ".jpeg" and need to group it, most of windows user may say "it is not stem but, simply "file extension", though we need to add "stem part" later. or they can not save as file.

It seems usual manner and thinking how we = windows user recognize these file related strings.

I think path _lib is easy way to manage "path" as object. or Do you think it as real file object? If you think, Path_lib is "file_path" object, I believe we can think ".png" is "part of Path". even though there is no real file.

(because sooner or later, we will add file "stem" with fle "extension" . it is manner how windows user save their files. then we think ".png" or ".txt" the file "stem is empty at current." it is usual thinking way at least for me.

At least I think, you can offer option (even thoufh only for windows user) , user may choose, when runb python, I hope so.

Is there any real problem, if you change stem for ".png" or ".txt" as I said? actually there seems no problem but so yours believe "it is correct word usage" then many user prefer not to use "PathLib" because it simply just add more work to manage file name or file path, witch include "flie extension" like .png .jpeg etc becase you treat "!.png" is file name.
then we need to use old way like this

if "." in raw:
name_part, ext_part = raw.rsplit(".", 1)
ext = "." + ext_part.lower() # ".png", ".jpeg"
else:
name_part = raw
ext = ""

It seems pity and shame of path-lib I feel. sorry I am not MLL then say what I feel honestly. I know, it is your professional thinking way. But if python change way about pathlib stem() there will be no need to use "spilit" etc just for devide "suffix" and "stem" to manage file path. If it work as document described. (but not work as it written, simply because you or developers think there should not be "suffix" without "stem" sirings., But you can think "stem" is empty now (it will be added by code) , but there is suffix. I prefer to think so, about ".png" (why not think offer as option which user can decide?)

[terryjreedy]

The behavior of Path.stem is consistent with the documented behavior of os.path.splitext.

Split the pathname path into a pair (root, ext) such that root + ext == path, and the extension, ext, is empty or begins with a period and contains at most one period. If the path contains no extension, ext will be ''. ... Leading periods of the last component of the path are considered to be part of the root:

splitext('.cshrc')
('.cshrc', '')
splitext('/foo/....jpg')
('/foo/....jpg', '')

In other words, an extension must follow a non-period in the last component. I verified the behavior on Windows.

Is there any real problem, if you change stem for ".png" or ".txt"

Yes, changing behaviors like this nearly always breaks someone's code. We very seldom do this unless a behavior violates the documentation, making it a bugfix. (And sometimes a conflict is fixed by changing the doc.)

[tokitoki22]

Pathlib sholud be made to set "file-path" more easy than os.path (include these cases), . But in your linked documents, there is no "stem" or "stem_with" and there is no "suffilx".

It just describe about "extension" and "the extension, ext, is empty or begins with a period and contains at most one period." whch somone decide so when describe about Os.path extension meaning.

Then we need to keeps rule which written for Os.path documents. and "extension"

There is no need PathLib suffix need to adapt same rule about OS. path "extension" manner. we simply need to use"suffix" or "stem" as natural thinking and logicall manner.
when someone separate word with dot, it better to keep rule about all case.

" aaa.bbb" >>> "aaa" = stem, ".bbb" = suffix
"a.bbb" >>> "a" = stem, ".bbb" = suffix
".bbb" >>> none or "" = stem, or you can say empty, but ".bbb" is suffix and it is same as others.
"." >>> none or "" = stem, "." = suffix
"aaa" >>> "aaa" = stem, there is no suffix.

Then you can say, it keep natulal thinking way and follow the word rule. (you need not use special case, which used for old Os. path, and not describe about new "stem" and "suffix" but describe, about "extension" which is ismply word to devide file name with dot.

Some one or many believer seems like to keep old strange rule, then say it is better we need to keep the bible,
(But the bible is too old , so we needed new bible, and offer new word, "Stem " and "suffix" which used for new Path_lib.
then we use them to separate file name with "dot".

New path_lib Path need not use same word and need not follow OS.path document. because there is new "stem" and "suffix".

Actually somone change way , "." consider as "valid suffix"
but yours seems not agree about ".png" is valid suffix.

I may suggest youys to make simple questionnaire , then ask, which is more logical thnking way. it show all case
and how set "stem" and "suffix" with dot.

I thnk most of guys think ".xxx" need to group as "suffix" should not set them as "stem" , If you set so, It is un-natural thinking way. But I know programmer not hope to change something untill many user against it.
So yours really like to "Close topic" even though it is "suggestion". (then hope to keep strange and un-natural naming rule for word usage,)

About this case, "Not planned" = some one not plan well and adapt orignal rule when devide words with "." , then it needed to plan again. But python developer seems to keep strange rule for Path-lib too.