[Python-Dev] Proposal to revert r54204 (splitext change)
Steve Holden
steve at holdenweb.com
Fri Mar 16 14:10:51 CET 2007
Martin v. Löwis wrote:
> Phillip J. Eby schrieb:
>> Some other options:
>>
>> 1. Deprecate splitext() and remove it in 3.0
>
> How would that help the problem? Isn't it useful to have a function
> that strips off the extension?
>
>> 2. Add an optional flag argument to enable the new behavior
>
> How would that help backwards compatibility?
>
By providing it!
The suggestion would retain the same behavior unless a newly-specified
aspect of the API is exercised, therefore avoiding gratuitous change to
existing programs' functionality. Since the default would be to behave
as the existing function does then you would have to specify a True
value for the "strange-and-incomprehensible-treatment-of-dotfiles" to
get the behavior as specified in the patch you just applied.
This seems like the best option to me, as clearly there are enough
different opinions about whether the old or the new behavior is a bug
that a user-selectable behavior is actually desirable.
My suspicion is that most users just won't care about dotfiles, and will
continue to use splitext as is. Windows users are always surprised to
see them appearing, but they are becoming more common as open source
functionality migrates to Windows. But those who do care (as you
obviously do) can use bizarreAndInexplicableDotfileBehavior=True ;-)
>> 3. Create a new function with the new behavior (as you proposed the last
>> time there was a patch submitted for this)
>
> What to do with the old function in this case?
>
Presumably keep it, thereby adding to the bloat in the language -
definitely NOT my preferred option.
regards
Steve
--
Steve Holden +44 150 684 7255 +1 800 494 3119
Holden Web LLC/Ltd http://www.holdenweb.com
Skype: holdenweb http://del.icio.us/steve.holden
Blog of Note: http://holdenweb.blogspot.com
See you at PyCon? http://us.pycon.org/TX2007
More information about the Python-Dev
mailing list