[prev in list] [next in list] [prev in thread] [next in thread] 

List:       python-dev
Subject:    Re: [Python-Dev] The path module PEP
From:       "Gustavo J. A. M. Carneiro" <gjc () inescporto ! pt>
Date:       2006-01-26 12:03:28
Message-ID: 1138277008.8256.26.camel () localhost
[Download RAW message or body]

On Wed, 2006-01-25 at 22:35 -0600, Ian Bicking wrote:
> Gustavo J. A. M. Carneiro wrote:
> >   On a slightly different subject, regarding path / path, I think it
> > feels much more natural path + path.  Path.join is really just a string
> > concatenation, except that it adds a path separator in the middle if
> > necessary, if I'm not mistaken.
> 
> No, it isn't, which maybe is why / is bad.  os.path.join(a, b) basically 
> returns the path as though b is interpreted to be relative to a.  I.e., 

> os.path.join('/foo', '/bar') == '/bar'.  Not much like concatenation at 
> all.

  Really?  This is not like the unix command line.  At least in
Linux, /foo/bar is the same as /foo//bar and /foo///bar, etc.  But I
admit it can be useful in some cases.

>   Plus string concatenation is quite useful with paths, e.g., to add 
> an extension.

  I see your point.  Although perhaps adding an extension to a file
should be the exception and not the rule, since adding extensions is
rarely used compared to joining paths?  Maybe Path.add_extension() ?

  BTW, regarding Path subclassing basestr, there exists "prior art" for
this Path thing in SCons.  In SCons, we (users, I'm not a scons dev)
have to constantly deal with Node instances.  Most scons functions that
accept Nodes also accept strings, but a Node is not a string.  When
calling an os function with Nodes, one has to convert it to string
first, using str().  IMHO, having to decorate Node instances with str()
sometimes is no big deal, really.  And, given enough time, perhaps most
of the python standard library could be enhanced to accept Path
instances in addition to C strings.

> If a URI class implemented the same methods, it would be something of a 
> question whether uri.joinpath('/foo/bar', 'baz') would return '/foo/baz' 
> (and urlparse.urljoin would) or '/foo/bar/baz' (as os.path.join does). 
> I assume it would be be the latter, and urljoin would be a different 
> method, maybe something novel like "urljoin".

  I honestly don't understand the usefulness of join('/foo/bar', 'baz')
ever returning '/foo/baz' instead of '/foo/bar/baz'.  How would the
former be of any use?  If it has no use, then please don't complicate
things even more :)

  Regards.

-- 
Gustavo J. A. M. Carneiro
<gjc@inescporto.pt> <gustavo@users.sourceforge.net>
The universe is always one step beyond logic.

_______________________________________________
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: http://mail.python.org/mailman/options/python-dev/python-dev%40progressive-comp.com
[prev in list] [next in list] [prev in thread] [next in thread]