PEP on path module for standard library

Michael Hoffman cam.ac.uk at mh391.invalid
Fri Jul 22 11:19:30 EDT 2005


George Sakkis wrote:

> Havind said that, I think
> the choice between subclassing or not is going to be a
> practicality-vs-purity decision. You're right, conceptually a path
> HAS_A string description, not IS_A string, so from a pure OO point of
> view, it should not inherit string. OTOH, people in favor of the
> subclassing point out the convenience for many (or most) common cases.

It would be an entirely different matter if we were designing a language 
from scratch. But we have to deal with an existing codebase that expects 
strings.

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. 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.

What are the practical advantages and conveniences of *not* subclassing 
from basestring?
-- 
Michael Hoffman



More information about the Python-list mailing list