[Patches] [ python-Patches-1681842 ] splitext of dotfiles, incl backwards compat and migration

SourceForge.net noreply at sourceforge.net
Fri Mar 16 17:35:12 CET 2007


Patches item #1681842, was opened at 2007-03-16 04:22
Message generated for change (Comment added) made by aptshansen
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1681842&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Library (Lib)
Group: Python 2.6
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Stephen Hansen (aptshansen)
Assigned to: Nobody/Anonymous (nobody)
Summary: splitext of dotfiles, incl backwards compat and migration

Initial Comment:
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.

----------------------------------------------------------------------

>Comment By: Stephen Hansen (aptshansen)
Date: 2007-03-16 16:35

Message:
Logged In: YES 
user_id=1720594
Originator: YES

File Added: splitext3.patch

----------------------------------------------------------------------

Comment By: Martin v. Löwis (loewis)
Date: 2007-03-16 15:50

Message:
Logged In: YES 
user_id=21627
Originator: NO

[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.

----------------------------------------------------------------------

Comment By: Stephen Hansen (aptshansen)
Date: 2007-03-16 08:00

Message:
Logged In: YES 
user_id=1720594
Originator: YES

File Added: splitext2.patch

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1681842&group_id=5470


More information about the Patches mailing list