Michael Hoffman wrote:
> Here's some code I just wrote seconds ago to construct a path for a
> scp upload:
>
> """
> DST_DIRPATH = path("host:~/destination")
> RSS_EXT = "rss"
>
> dst_filenamebase = os.extsep.join([postcode.lower(), RSS_EXT])
> dst_filepath = DST_DIRPATH.joinpath(dst_filenamebase)
> """
>
> With the current path implementation, this Just Works.
It isn't at all obvious to me that it works:
>>> import os
>>> from path import path
>>> postcode = "AA2 9ZZ"
>>> DST_DIRPATH = path("host:~/destination")
>>> RSS_EXT = "rss"
>>>
>>> dst_filenamebase = os.extsep.join([postcode.lower(), RSS_EXT])
>>> dst_filepath = DST_DIRPATH.joinpath(dst_filenamebase)
>>> print dst_filepath
host:~/destination\aa2 9zz.rss
> If I were using
> something that parsed and understood paths, the scp/rcp convention of
> host:filename would either cause an error or have to be programmed in
> separately. The current implementation is much more flexible.
You still have to program your scp path separately from your filesystem
path in order to handle the different conventions for path separator
characters and maybe also escaping special characters in the path (I don't
use scp much so I don't know if this is required).
> What are the practical advantages and conveniences of *not*
> subclassing from basestring?
Simplification of the api: not having methods such as center, expandtabs
and zfill.
Not having the base class change from str to unicode depending on which
system you run your code?
Fewer undetected bugs (explicit is better than implicit)?
Perhaps none of these matter in practice. As I said elsewhere I haven't
used path for anything real, so I'm still finding surprises such as why
this doesn't do what I expect:
>>> p = path('a/b')
>>> q = path('c/d')
>>> p+q
path(u'a/bc/d')
If path didn't subclass string then either this would have been
implemented, and probably would Do The Right Thing, or it wouldn't be
implemented so I'd quickly realise I needed to do something else. Instead
it does something suprising.
--
http://mail.python.org/mailman/listinfo/python-list
