Re: [Python-Dev] Proposal to revert r54204 (splitext change)

[Ronald Oussoren]

On 20 Mar, 2007, at 15:54, Phillip J. Eby wrote:

At 09:24 AM 3/20/2007 +0100, Ronald Oussoren wrote:

I don't agree. "all_ext=True" is won't do the right thing in a
significant subset of filenames

Yes, that's understood. The problem is that splitext() in general "won't do the right thing", for many definitions of "the right thing", unless you're applying it to a fairly constrained range of filenames, or unless you add other code. This won't change, unless we get rid of splitext() altogether.

I know that, I actually read most of the messages in this thread. The reason I'm pointing this out for the 'all_ext=True' case is that adding this flag could give naive users even more reason to believe that splitext will magicly do the right thing.

If you're trying to match an archive extension, for example, you'll probably need to loop on repeated splitext() calls until you find an extension that matches. One benefit of using both the new keyword arguments together is that it allows you to make your loop proceed from longest match to shortest, so that if you are matching product-X.Y.Z.tar.gz, you're going to go through matching .Y.Z.tar.gz, then .Z.tar.gz, then .tar.gz.

I don't know if this is worth the additional API complexity. Especially given the inherit problems of a splitext function.

The ignore_leading_dot argument also doesn't buy you anything that can't

trivially be implemented in other ways.

I don't understand.  Example?

You conveniently ignored my other arguments ;-).


      # from os.path import *
      def splitext2(path):
            dn = dirname(path)
            bn, ext = splitext(basename(path))
            if bn.startswith('.') and ext == '':
                return dn, bn + ext
            else:
               return join(dn, bn), ext

I'd say that's a trivial function.



Ronald

Given a splitext that ignores leading dot's the following function doesn't: What I don't understand is why 'ignore_leading_dot==False' is considered to be a valid usecase at all, except for the fact that os.path.splitext did this until py2.5. I'm definitely in the camp that considers '.profile' not to have an extension.

smime.p7s
Description: S/MIME cryptographic signature

_______________________________________________
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