On 01:04 am, email@example.com wrote:
If you're serious about writing platform-agnostic pathname code, you don't put slashes in the arguments at all. Instead you do
os.path.join("hello", "slash", "world")
Many of the other things you mention are also a result of not treating pathnames as properly opaque objects.
Of course nobody who cares about these issues is going to put constant forward slashes into pathnames. The point is not that you'll forget you're supposed to be dealing with pathnames; the point is that you're going to get input from some source that you've got very little control over, and *especially* if that source is untrusted (although sometimes just due to mistakes) there are all kinds of ways it can trip you up. Did you accidentally pass it through something that doubles or undoubles all backslashes, etc. Sometimes these will result in harmless errors anyway, sometimes it's a critical error that will end up trying to delete /usr instead of /home/user/installer-build/ROOT/usr. If you have the path library catching these problems for you then a far greater percentage fall into the former category.
If you're saying that the fact they're strings makes it easy to forget that you're supposed to be treating them opaquely,
That's exactly what I'm saying.
- although individual operations are atomic, shutil.copytree and friends
aren't. I've often seen python programs confused by partially-copied trees of files.
I can't see how this can be even remotely regarded as a pathname issue, or even a filesystem interface issue. It's no different to any other situation where a piece of code can fall over and leave a partial result behind.
It is a bit of a stretch, I'll admit, but I included it because it is a weakness of the path library that it is difficult to do the kind of parallel iteration required to implement tree-copying yourself. If that were trivial, then you could write your own file-copying loop and cope with errors yourself.