[Python-Dev] splitext('.cshrc') (original) (raw)

Stephen Hansen apt.shansen at gmail.com
Fri Mar 9 03:08:20 CET 2007

I'm a long-term lurker and Python coder, and although I've never really contributed much to the list, I do make a point to keep up on it so I'm prepared at least when changes come through. This thread's gone on forever, so I thought I'd offer my opinion :) Mwha.

Ahem.

First of all, I think the current behavior is clearly broken; ".cshrc" is a file without an extension and marked as 'hidden' according to the conventions of the operating system. I totally think it should be fixed; but with others I'm worried about backwards compatability and more importantly the possibility of silent failures. Although none of my company's code will be hit (as I've always done fn.split('.')[-1] just... because it strikes me as more natural -- then again I'm in a situation where I don't have user-supplied filenames.), the thought that it's OK to make such changes even in a 'major' release is a bit disconcerting.

Its not that I don't think there can be backwards-incompatible changes, but if at all possible they should be done in such a way that the change causes a hard failure or at least a clear warning in the offending code. I read that someone (... No idea who) suggested an optional keyword argument, and someone else objected to that on the grounds that it would let a second argument be passed in to alter the signature, and it would no longer throw an exception as people would be expecting.

Well, I think it was a great idea-- whoever said it :) And gives the oppertunity to use the transitory period before 3.0 to loudly warn people about this fix. I don't expect a lot of people will be hit by it, but isn't that why this whole 2.6-to-3.0 thing is going on?

Why wouldn't this work? I could submit a patch with a doc modification and tests even :P But it could begin the process of 'fixing' it, and warn people of the upcoming breakage, and although it slightly complicates the function... I think it only does it slightly :)

(BTW, it raises a TypeError if the allow_dotfile isn't specified specifically, to address someone's objection that it would alter the signature)

import warnings def splitext(p, **kwargs): allow_dotfile = kwargs.pop('allow_dotfile', False)

if kwargs:
    raise TypeError, "splitext() takes at most 2 arguments (%s given)" %

(1 + len(kwargs))

i = p.rfind('.')
if i<=max(p.rfind('/'), p.rfind('\\')):
    fn, ext = p, ''
else:
    fn, ext = p[:i], p[i:]

if allow_dotfile is False:
    if p.find('.') == 0:
        warnings.warn(FutureWarning('In Python 3.0, allow_dotfile

default will become True.')) return fn, ext else: if p.find('.') == 0: return ext, '' else: return fn, ext

-------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.python.org/pipermail/python-dev/attachments/20070308/55d1712f/attachment.htm

More information about the Python-Dev mailing list