[Python-Dev] Path object design (original) (raw)

Jonathan Lange jml at mumak.net
Wed Nov 1 12:57:43 CET 2006

On 11/1/06, 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 <http://twistedmatrix.com/documents/current/api/twisted.python.filepath.FilePath.html>, 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/publichtml')) 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.

Then let us discuss that. Is FilePath actually a better interface to the old functionality? Even if it was designed to solve a security problem, it might prove to be an extremely useful general interface.

jml

More information about the Python-Dev mailing list