Julian Foad wrote:
>>> Presumably, for multiple source paths, the destination must be a
>>> directory into which the sources will be moved, whereas for a single
>>> item it can be the new name for the item. (This part of the doc string,
>>> about "dst_path", is already ambiguous; I've just posted a patch to
>>> clarify it.)
>>> I think we might well need to use two separate functions, one for moving
>>> (and possibly renaming) a single item, and one for moving multiple (one
>>> or more) items without renaming them. Otherwise, if only one source
>>> item is specified, how do we know whether the destination path or url
>>> represents the new _name_ for the item or the new _directory_ in which
>>> to place it?
>> Wouldn't it be possible to just check and see if the destination is a
>> target when there is more than one source? If that case were not met,
>> we could error.
> (I assume you mean "directory" instead of "target".)
Yes. My hands sometimes have a mind of their own. :)
> No, I don't think we can just check, because I think the "multiple
> files" mode needs to work in the same way regardless whether the number
> of files is one or more than one, and the way it needs to work (the
> destination always being a directory in which to put the sources) is
> incompatible with the current semantics for one file.
Ah, the light just turned on. :) This could probably be accomplished
without a rev of the current API, just an addition. We would still do
some preliminary checking in the client application to see which API to
call (e.g., are we renaming a file, or are we moving just one file to a
Such an addition to the API would also make it possible to eventually
implement "true renames", instead of the current "delete and add"
Received on Fri Nov 18 05:54:57 2005