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 _______________________________________________ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com