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

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