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