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-19 19:43
Message:
Logged In: YES
user_id=1720594
Originator: YES
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. :)
----------------------------------------------------------------------
Comment By: Jim Jewett (jimjjewett)
Date: 2007-03-19 02:45
Message:
Logged In: YES
user_id=764593
Originator: NO
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.
----------------------------------------------------------------------
Comment By: Bj�rn Lindqvist (sonderblade)
Date: 2007-03-18 21:29
Message:
Logged In: YES
user_id=51702
Originator: NO
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.
----------------------------------------------------------------------
Comment By: Stephen Hansen (aptshansen)
Date: 2007-03-16 22:36
Message:
Logged In: YES
user_id=1720594
Originator: YES
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
----------------------------------------------------------------------
Comment By: Stephen Hansen (aptshansen)
Date: 2007-03-16 16:52
Message:
Logged In: YES
user_id=1720594
Originator: YES
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 :)
----------------------------------------------------------------------
Comment By: Georg Brandl (gbrandl)
Date: 2007-03-16 16:48
Message:
Logged In: YES
user_id=849994
Originator: NO
I don't understand why you have to use **kwargs.
----------------------------------------------------------------------
Comment By: Stephen Hansen (aptshansen)
Date: 2007-03-16 16:36
Message:
Logged In: YES
user_id=1720594
Originator: YES
That's a good point; updated patch to throw an error if other keyword
arguments are given.
----------------------------------------------------------------------
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
_______________________________________________
Patches mailing list
Patches@python.org
http://mail.python.org/mailman/listinfo/patches
