Reinhold Birkenfeld wrote:
> Peter Hansen wrote (on Paths not allowing comparison with strings):
>>Could you please expand on what this means? Are you referring to doing
>>< and >= type operations on Paths and strings, or == and != or all those
>>or something else entirely?
>
> All of these. Do you need them?
I believe so. If they are going to be basestring subclasses, why should
they be restricted in any particular way? I suppose that if you wanted
to compare a Path to a string, you could just wrap the string in a Path
first, but if the Path is already a basestring subclass, why make
someone jump through that particular hoop?
>>>Other minor differences, as requested on python-dev, are:
>>>
>>>* size property -> getsize() method.
>>>* atime/mtime/ctime properties -> atime()/mtime()/ctime() methods
>>
>>What does this mean? The .size property and a getsize() method both
>>already exist (in my copy of path.py anyway) and do the same thing.
>>Same with the other ones mentioned above. Is someone working from an
>>out-of-date copy of path.py?
>
> No. But the size of a file is somewhat volatile, and does not feel like
> a "property" of the path to it. Remember: the path is not the file. Same
> goes with the xtime() methods.
Oh, so your original text was meant to imply that those properties *were
being removed*. That wasn't at all clear to me.
I understand the reasoning, but I'm unsure I agree with it. I fully
accept that the path is not the file, and yet I have a feeling this is a
pedanticism: most of the time when one is dealing with the _file_ one is
concerned with the content, and not much else. When one is dealing with
the _path_ one often wants to check the size, the modification time, and
so forth. For example, once one has the file open, one very rarely is
interested in when it was last modified.
In other words, I feel once again that Jason's original intuition here
was excellent, and that he chose practicality over purity in appropriate
ways, in a very Pythonic fashion. I confess to feeling that the
suggested changes are being proposed by those who have never actually
tried to put path.py to use in practical code, though I'm sure that's
not the case for everyone making those suggestions.
Still, once again this doesn't seem a critical issue to me and I'm happy
with either approach, if it means Path gets accepted in the stdlib.
> At the moment, I think about overriding certain string methods that make
> absolutely no sense on a path and raising an exception from them.
That would seem reasonable. It seems best to be very tolerant about
what "makes no sense", though istitle() would surely be one of those to
go first. Also capitalize() (in spite of what Windows Explorer seems to
do sometimes), center(), expandtabs(), ljust(), rjust(), splitlines(),
title(), and zfill(). Hmm... maybe not zfill() actually. I could
imagine an actual (if rare) use for that.
>>.bytes() and friends have felt quite
>>friendly in actual use, and I suspect .read_file_bytes() will feel quite
>>unwieldy. Not a show-stopper however.
>
> It has even been suggested to throw them out, as they don't have so much to
> do with a path per se. When the interface is too burdened, we'll have less
> chance to be accepted. Renaming these makes clear that they are not operations
> on the path, but on a file the path points to.
Here again I would claim the "practicality over purity" argument. When
one has a Path, it is very frequently because one intends to open a file
object using it and do reads and writes (obviously). Also very often,
the type of reading and writing one wants to do is an "all at once" type
of thing, as those methods support. They're merely a convenience, to
save one doing the Path(xxx).open('rb').read thing when one can merely
do Path(xxx).bytes(), in much the same way that the whole justification
for Path() is that it bundles useful and commonly used operations
together into one place.
> Phillip J. Eby suggested these to be set_file_xxx and get_file_xxx to
> demonstrate
> that they do not read or write a stream; how about that?
If they are there, they do exactly what they do, don't they? And they
do file.read() and file.write() operations, with slight nuances in the
mode passed to open() or the way the data is manipulated. Why would one
want to hide that, making it even harder to tie these operations
together with what is really going on under the covers? I think the
existing names, or at least ones with _read_ and _write_ in them
somewhere are better than set/get alternatives. It's just rare in
Python to encounter names quite as cumbersome as _write_file_bytes().
It might be good for those involved to discuss and agree on the
philosophy/principles behind using Path in the first place. If it's one
of pragmatism, then the arguments in favour of strictly differentiating
between path- and file- related operations should probably not be given
as much weight as those in favour of simple and convenient access to
commonly needed functionality. If, on the other hand, Path is seen as
some kind of a Java-esque universal path object which is cleanly and
tightly decoupled from everything else, then it would probably be best
to eliminate things like .getsize() and .read_file_bytes()/.bytes()
entirely and leave those in the hands of the cleanly defined and tightly
decoupled File object (currently spelled "file"?), again in a Java-esque
fashion. IMHO. :-)
(I'll like to say for the record that I feel that just about *any* form
of Path with even just the basics, basestring-based or not, would be a
huge improvement over the status quo, and I'm not trying to make a big
war out of this. Just offering my own view as a recent (a month or two
ago) but very enthusiastic convert to path.py.)
-Peter
-Peter
--
http://mail.python.org/mailman/listinfo/python-list
