[Python-ideas] Object interface to path names

Devin Jeanpierre jeanpierreda at gmail.com
Tue Sep 13 17:16:10 CEST 2011


There are existing implementations of this sort of OOP approach, I
think it'd be worth trying to adopt one of them instead of creating a
new ad-hoc interface.

Here are the two that come to mind:

http://twistedmatrix.com/documents/10.1.0/api/twisted.python.filepath.FilePath.html

https://bitbucket.org/birkenfeld/sphinx/src/cf794ec8a096/tests/path.py

I support including such an API (+1), but I don't believe you
mentioned my preferred use-case:

Having an object-oriented / polymorphic file API means that one can
provide file objects that aren't backed by the filesystem, but look
the same. This is cool in that you can do things like treat zip files
as directory, or mock out the filesystem for a unit test, without
worrying about monkeypatching builtins or using a nonstandard wrapper
API etc.

Devin

On Tue, Sep 13, 2011 at 11:03 AM, David Townshend <aquavitae69 at gmail.com> wrote:
> I've recently been developing a tool to track changes to a fairly large
> structured file system, and in the process got to thinking about how working
> with path names could be improved. The problems I've had with using just os
> and os.path have lead to three objectives of any new implementation:
> 1.  Cleaner handling of paths names, specifically constructing path names
> without the need for a lot of nested os.path.join() and os.split()
> functions.
> 2.  Allow a validation of paths names based on predefined rules. (Although
> this requirement might be very specific to my use case)
> 3.  Allow caching of file attribute data so that queries do not have to wait
> the disk or network to respond (although at the cost of accuracy).
> The first can be met with behaviour as follows, basically handling paths as
> containers of sub-paths:
>>>> root = Path('/usr')
>>>> print([n for n in root])
> ['bin', 'local', 'lib', 'share']
>>>> print([n for n in root.dirs])
> ['bin', 'local', 'lib', 'share']
>>>> print([n for n in root.files])
> []
>>>> root['local/share']
> Path('/usr/local/share')
>>>> root['/usr/local/share']
> Path('/usr/local/share')
>>>> share = Path('/usr/local/share')
>>>> share in root
> True
> The second can be met by allowing Path to be subclassed and defining factory
> functions for the creation of sub-paths:
>>>> root = Path('/usr')
>>>> root.factory = my_factory_function
>>>> root['local/share']
> MyPath('/usr/local/share')
> The third can be met be allowing all disk calls to be asynchonous:
>>>> path = Path('/home/david/newfile', async=True)
>>>> path.touch()
>>>> path.exists()
> False
>>>> time.sleep(2)
>>>> path.exists()
> True
> This could all be implemented in pure python using os and os.path, and
> threading for asynchonous calls. I haven't yet thought through a complete
> specification for Path, but I image it would need to contain functions such
> as exists(), isfile(), isdir(), stat(), walk(), and allow iterator access to
> children.
> Does anyone else see a usefulness for this?
> Regards
> David
>
> _______________________________________________
> Python-ideas mailing list
> Python-ideas at python.org
> http://mail.python.org/mailman/listinfo/python-ideas
>
>



More information about the Python-ideas mailing list