Greg Ewing wrote:
> Nick Coghlan wrote:
>
>> So I suggest splitting the internal data into 'path elements separated
>> by os.sep', 'name elements separated by os.extsep'
>
> What bothers me about that is that in many systems
> there isn't any formal notion of an "extension",
> just a convention used by some applications.
>
> Just because I have a "." in my filename doesn't
> necessarily mean I intend what follows to be
> treated as an extension.
This is an interesting point - I've been tinkering with this a bit (despite my
best intentions about not getting distracted by the topic ;), and it's
starting to look like treating directory paths and file paths identically
poses significant problems for an object-oriented API.
For example, appending a filename or a relative directory path to an existing
directory path is fine (giving a filename or directory path as the result),
but you can't do either to a filename.
Listing the entries or walking a file doesn't make any sense either.
And extension information is typically significant only for filenames, not for
directories.
When paths are just strings, the distinction doesn't matter because the
instances have no inherent behaviour - it is the application that carries the
state regarding whether something is meant to be a directory name or a file name.
So it makes a lot more sense to have separate Dirpath and Filepath (and
possibly Linkpath) objects - from an OO point of view, the methods provided
for each of these kinds of filesystem entities will be significantly
different. A common parent Path object may still make sense if there's
sufficient overlap, though (e.g. retrieving status related information).
Cheers,
Nick.
--
Nick Coghlan | ncoghlan at gmail.com | Brisbane, Australia
---------------------------------------------------------------
http://www.boredomandlaziness.org
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4