[Python-Dev] Path object design

Jean-Paul Calderone exarkun at divmod.com
Wed Nov 1 15:09:48 CET 2006

On Wed, 01 Nov 2006 11:06:14 +0100, Georg Brandl <g.brandl at gmx.net> wrote:
>glyph at divmod.com wrote:
>> On 03:14 am, sluggoster at gmail.com wrote:
>>  >One thing is sure -- we urgently need something better than os.path.
>>  >It functions well but it makes hard-to-read and unpythonic code.
>> I'm not so sure.  The need is not any more "urgent" today than it was 5
>> years ago, when os.path was equally "unpythonic" and unreadable.  The
>> problem is real but there is absolutely no reason to hurry to a
>> premature solution.
>> I've already recommended Twisted's twisted.python.filepath module as a
>> possible basis for the implementation of this feature.  I'm sorry I
>> don't have the time to pursue that.  I'm also sad that nobody else seems
>> to have noticed.  Twisted's implemenation has an advantage that it
>> doesn't seem that these new proposals do, an advantage I would really
>> like to see in whatever gets seriously considered for adoption:
>Looking at
>it seems as if FilePath was made to serve a different purpose than what we're
>trying to discuss here:
>I am a path on the filesystem that only permits 'downwards' access.
>Instantiate me with a pathname (for example,
>FilePath('/home/myuser/public_html')) and I will attempt to only provide access
>to files which reside inside that path. [...]
>The correct way to use me is to instantiate me, and then do ALL filesystem
>access through me.
>What a successor to os.path needs is not security, it's a better (more pythonic,
>if you like) interface to the old functionality.

No.  You've misunderstood the code you looked at.  FilePath serves exactly
the purpose being discussed here.  Take a closer look.


More information about the Python-Dev mailing list