The attached patch is for the *path.py files, the associated test suits, and the documentation-- the latter part which may need a staring at since I don't really know LaTeX very well. It's made against the HEAD in the trunk.

This is in response to issue #1462106, which has earned quite a bit of discussion on python-dev.

I am in complete agreement with the *intention* of that patch and its application, that the previous behavior was "wrong"; that splitext('.cshrc') should not return ('', '.cshrc').

However, the patch silently altered the semantics of the function instead of firmly failing, and doesn't allow for the fact that the previous documentation was ambiguous and as such people may (and apparently, sometimes did) actually consider the old behavior correct.

The attached patch adds a keyword parameter to splitext, "preserve_dotfiles", which at present defaults to False.

It might need a better name :P I suck at that.

When False, the behavior is to return ('', '.cshrc'), but also to issue a FutureWarning indicating that this will change in the future.

When True, the behavior is to return ('.cshrc', '').

The intention is to fix the 'error', while giving people time to migrate code which may have previousely been faulty to the correct result. Also, for those not of a deeply UNIX mindset, they can consider everything after the last dot-- regardless of how many-- an extension, even if it means there's no root. Viva la Windows Explorer.

File Added: splitext2.patch

[ignoring the question whether this change is acceptable in the first place - I'm apparently not qualified to make a determination here]

This implementation makes splitext accept arbitrary many keyword arguments. This is not good, it should only accept those that are documented.

It might be helpful if the warning was only issued if the keyword argument wasn't provided at all, assuming that whoever passes False knows what he does.

File Added: splitext3.patch

That's a good point; updated patch to throw an error if other keyword arguments are given.

I don't understand why you have to use **kwargs.

Well, because someone on the -dev list at some point raised an objection to taking an arbitrary positional argument in as a second argument and not throwing an error. Or something like that.

splitext('filename.ext', '.')

would make '.' head along into preserve_dotfiles

If that's not a concern, I could readily just type-check to make sure preserve_keywords is only one of (True, False) and if not raise an error.

Its a "keyword-only-argument", before such a thing is in :)

I should probably not submit a patch in the *middle* of a conversation, huh? I thought it was at the point where people were just debating things like.. policy... and.. stuff. And not at a point where someone would come up a whole new idea that ties directly in.

Someone did! Nick Coghlan came up with a better way to spell the whole issue, and a logical companion feature; so I just implemented the patch that way. splitext(path, ignore_leading_dot=False, all_ext=False)

Also added a bunch to the test just to be anal about being sure that no combination of options would screw up the 'default' behavior.
File Added: splitext-leading_dot+all_ext.patch

Please no, there is no need to bastardize both the implementation and
the specification of splitext just to appease those 0.0001% of its
users that has ever splitext:ed a dotfile. For the rest of the
functions 99.99% users, the extra flags are just dead and confusing
weight. Functions should not be kitchen sinks, they should do one
thing only. If there is a need to split Python-2.4.3.tar.bz2 into
("Python-2.4.3", ".tar.bz2") or other unix:y variants, such a function
would be much better added to shutil.

Please just choose whether splitext(".emacs") returns ("", ".emacs")
or (".emacs", "") and update the doc to be more explicit. Keep it
simple.

If it has to be a simple decision, we need to keep the current behavior;  test/test_ntpath.py has been explicitly verifying the current behavior since 2002.

The question is whether the spec is buggy enough to fix, either in 2.x or in 3.0.

As to Bastardization of Implementations; I think from the endless conversation it became obvious (to me at lest) that just what "extension" means is actually somewhat domain-specific, and splitext doesn't really do it's "one thing" very well. 

I think "ignore_leading_dot" is nessecary, regardless of which behavior is default and regardless of if it becomes determined warnings are bad. Dotfiles do exist: on the various *Nix's, and on Mac's too-- I have about a dozen on my primary machine which is a mac in my home directory. Taking them into consideration is important, and there doesn't seem to be a clear opinion on how to treat the dot. So let people decide. IMHO.

I think "all_ext" is quite useful in many situations; that'd be the one I'd actually have used on more then one occasion in the past. I never used splitext because of its lack. And not on UNIX :) My company develops for Windows and OSX.

Either way, I'm curious what the pronouncement will be :) I'll probably update the patch to do whatever is decided is right (assuming that the status-quo of the original modification isn't determined to be right) This doesn't actually affect me at all (due to never using splitext as above noted), I just made the patch because I had time, it was an interesting, and I had an opinion on what was right-- so figured I'd back it up :) It's been more a test-case on getting involved with contributing to python. And an interesting one. :)

Still needs a pronouncement. IMHO, should be included in the CoobBook or
PyPI if it doesn't get added to the standard lib.

If I ever clear all the other issues off my list, I may get a chance to have a closer look at this one :)

Add Michael Foord to nosy list as he raised #1462106 which refers to #1115886 where msg24154 states "fixed this in r54204".  Can this be closed?

On Python 2.6.5:

>>> os.path.splitext('.cshrc')
('.cshrc', '')

I believe this can be closed.