[Python-3000] Mini Path object

[Mike Orr]

On 11/9/06, Talin <talin at acm.org> wrote:
> Mike Orr wrote:
> > On 11/9/06, Talin <talin at acm.org> wrote:
> >> (This is a good reason to have paths represented as strings instead of
> >> as a tuple, since you can't defer interpretation this way with
> >> pre-parsed paths.)
> >
> > Er, is there an API recommendation in there somewhere, or is this just
> > philosophy or usage style?
>
> I am indeed trying to describe a usage style, one that is not only used
> by me but by a large number of pre-existing apps. My goal in describing
> this is to insure that any new path system allows similar kinds of usage
> patterns.
>
> What I am arguing against is an overly strict and pedantic
> interpretation of the differences in path representation across
> platforms. True, in theory, you can't compare a windows path with a
> posix path, but in practice it generally "just works".
>
> I sometimes notice a tendency on this list that anything which is not
> 100% provably correct should be forbidden, no matter how useful it is.
>
> Let me give a concrete example: In my TurboGears project, there is a
> file called "thes.egg-info/sqlobject.txt" that contains this string:
>
>         history_dir=$base/thes/sqlobject-history
>
> I didn't write this, it was generated by the 'quickstart' script. I
> fully expect to be able to package up my TG app from my OSX machine,
> transport it to my Windows box, and have it work. And I would fully
> expect to be able to do the same in any future version of TurboGears
> running on a future version of Python.
>
> Now, one can argue that this string is meaningless when taken from one
> platform to another, but the only thing that is accomplished by that
> argument is to remove functionality that current users find useful and
> valuable.

I'm looking for "we need a method named foo with signature bar that
does this..."     Or "make sure method blah doesn't do this...."
Otherwise I don't know what to do with the information.  Can you make
a use case showing how you'd ideally like to interact with the module
(what you'd call) and what it should do, starting wtih a config file
fragment and ending with a file operation (mkdir, open, etc).

In the case above, the question is how TurboGears would interact with
the new path module.  First we'd need to know what TG is doing
internally now; then we can verify we're not losing any functionality.
  I would guess TG is doing a text substitution of $base and not even
using a join function.  That's outside of our control.  We know that
our join/combine method is tied to a particular platform, and if given
two path fragments from that same platform will join them properly.
Beyond that all bets are off -- no using the wrong platform class, and
no mixing path fragments from different platforms.  You can't combine
"C:\" and "thes/sqlobject-history" into anything useful.  But
os.path.join() has the same restrictions.

On Windows you're depending on "something below Python" to interpret
the forward slashes properly when you do a file operation.  This is
outside the path module's scope.  But it looks like we'll be adding
the ability to convert at least some paths from Posix to Windows --
something os.path doesn't do.

-- 
Mike Orr <sluggoster at gmail.com>