path module

[Bengt Richter]

On Tue, 8 Jul 2003 20:28:52 +0200, holger krekel <pyth at devel.trillke.net> wrote:
[...]
>
>but i use the same idea (filter-functions) for more advanced walkers:
>
>    p = path('/music')
>    for i in p.filterwalk(AND(nolink, isfile, isplayable, match(repattern))):
>        play_mp3(i)
>
>where filterwalk is a generator because i don't want the playscript to 
>first try to gather *all* files for obvious reasons (as would happen with 
>list comprehension).  This has proven to be incredibly useful and easy to
>read (if you don't engange in list-comprehension <-> functional-style
>wars).  Just because Guido somewhat dislikes "functional support" like
>lambda, map, filter and friends to be in the __builtin__ module 
>doesn't mean it's bad :-)
>
What if we had a file systems package from which to import support
for various file system access, e.g.,

    from filesystems import fs_win32share   # might e.g., use or clone samba infrastructure?
    puterfs = fs_win32share.mount(r'\\puter\sharename') #(cf. virtual block device steps below)
    p = puterfs.path(r'\music')
    for i in p.filterwalk(AND(nolink, isfile, isplayable, match(repattern))):
        play_mp3(i)

... i.e., play mp3's stored as windows shared files via LAN.

Taking a cue from os.path, which is posixpath for slackware linux, and ntpath for NT4, perhaps
they could be callable as os.path('/some/path/to/a/dir') to create a path object suitable for
the default file system, referring to the specified directory. A path object could then
have a file method, and the builtin file function might really be the bound method os.path('').file.
It isn't right now, so I write it out below to be clear. An useful binding might be os.file also.

    from filesystems import f_as_blockdev
    a_drive_vbd = f_as_blockdev.mount(os.path('').file(r'\\.\A:')) # physical NT floppy A
    from filesystems import fs_apple
    applefdfs = fs.apple.mount(a_drive_vbd)
    srcp = applefdfs.path(r'\music')
    dstp = os.path('.')
    for i in p.filterwalk(AND(nolink, isfile, isplayable, match(repattern))):
        dstp.copy(i)

or maybe looking at a CDROM  file as an apple floppy image, and copying some files to the
local file system, e.g.,

    from filesystems import f_as_blockdev
    a_drive_img_vbd = f_as_blockdev.mount(os.path('').file(r'X:\apple\floppies\fdimg.1')) # CDROM X:
    from filesystems import fs_apple
    applefdfs = fs.apple.mount(a_drive_img_vbd)
    srcp = applefdfs.path(r'\music')
    dstp = os.path('.') # assumes callable instantiates path object for default local file system
    for i in p.filterwalk(AND(nolink, isfile, isplayable, match(repattern))):
        dstp.copy(i) # assumes copy method copying to './filename' for filter-surviving filenames.

Etc., etc., (ok, very short songs on floppy ;-)

I.e., path magic would be file-system-appropriate, yet provide a uniform generic interface
with reasonable (but presumably configurable in some file-system-specific ways) defaults.

File systems would be mounted using virtual block devices, unless the mount method for the
file system can reasonably bypass that to synthesize a file system object using non-block/char
device access, e.g., as a local proxy object for a remote file system (or virtual file-system
view, e.g., of an html href/imgref tree or news thread, or database, etc. etc.).

<ramble>
Note that a virtual file system could well have GUI side effects when written to. The frame buffer
device would be interesting to capture access to via a virtual file system module along the lines of
the above. Note also that GUI windows have a hierarchy that could map to a virtual file object hierarchy.
Imagine a virtual svg file system mounted to an x-window instance, so that when you wrote svg source
to it you would get the visual effects in that window. Alternatively, mount on a full-screen virtual
device, etc. Creating virtual sub-"directories" could create child windows...

I see various plotting packages factored into this form as well. And binary mode writes for fast
stuff. For grahic vfs's IWT their mount methods should accept a virtual frame buffer device, so
that something transparent and fast can ultimately talk almost directly to hardware. Maybe it
could be prototyped using tkinter infrastructure, though. Or pygame/sdl.

I've been thinking of prototyping a simple plotting graphic vfs along the above lines. Maybe its
calcomp driver writing nostalgia (I wrote a rasterizing driver to plot calcomp command streams on
a versatec 'way back. Of course a random access canvas will make it easier (there wasn't space
to brute force a full image and then feed the raster plotter ;-)
</ramble>

Just a couple of thoughts to throw in the idea hopper (this variation HOTTOMH, so very alpha ;-)
Too many irons in the coals (not to say fire ;-/)

Regards,
Bengt Richter