FYI: I modified the path module a bit so that it fits many of the suggestions from python-dev, and put the result in the Python CVS tree under nondist/sandbox/path.
Most prominent change is that it doesn't inherit from str/unicode anymore. I found this distinction important, because as a str subclass the Path object has many methods that don't make sense for it. Peter Hansen wrote: > Michael Hoffman wrote: >> For the PEP, do any of you have arguments for or against including path? >> Code samples that are much easier or more difficult with this class >> would also be most helpful. > > I believe the strongest argument for "path" can be made for how it > integrates functionality which, although closely related conceptually, > is currently distributed across a half dozen or more different modules > in the standard library. Especially for newbies (I can only imagine, at > this stage) it would make working with files much easier in a many ways. > > "Easier" or "more difficult" is a subjective thing, of course, but one > can't argue with the fact that path can sometimes do through a single > object what would otherwise require several imports and a bunch of calls > into things like open(), os.path, grep, and shutil. Correct. > Examples showing effective uses of path that simplify those cases would > probably merit the label "easier" even in Guido's mind, though > unfortunately that's not certain. "Easier" in some minds might simply > translate to "many lines less code", and while path can sometimes do > that, aside from the ease of splitting and joining stuff without > multiple calls to os.path.this-and-that, it really doesn't often reduce > code size _that_ much, in my experience. (Postings to c.l.p showing a > 50% reduction in code size for contrived examples notwithstanding.) Well, these examples are the ones we'd like to see here. So, people: If you posted examples to c.l.py in the past, please try to collect them here! > A related thoughts: since paths are objects, they have attributes or > properties, and having things like ".basename" and ".parent" readily > available without having to do obscure things like > os.path.split(somepath)[0] makes things much easier to read (therefore > more maintainable). In fact, I'd propose that as another strong > argument in path's favour: it makes code much more readable, even if not > "easier" to write. > > Hmm... does "easier" or "more difficult" apply to the writing of the > code or the reading of it? I find it self-evident that code written > using "path" is much easier to read, not necessarily much easier to > write (for non-newbies). And it is much more "Pythonic" in my eyes. Though that word may be inaccurate when it comes from someone else that Guido, I feel that endless chains of '[os.path.join(os.path.join(z, "a"), x) for x in os.path.listdir(os.path.join(z, "a") if os.path.isfile(os.path.join(.... are not qualified as being Pythonic. > I'd summarize this by saying that the integration of "path" in the > stdlib would make it easier for newbies to write code (that might not be > obvious to a non-newbie... shall we ask some to help?), and easier for > everyone to read code (self-evident, no?), and if that's not a > sufficient condition for inclusion I don't know what is. Reinhold -- http://mail.python.org/mailman/listinfo/python-list
