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.


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


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, ''
       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
       if p.find('.') == 0:
           return ext, ''
           return fn, ext

Python-Dev mailing list

Reply via email to