Author ncoghlan
Recipients eric.araujo, ncoghlan, pitrou, vstinner
Date 2011-11-06.01:25:01
SpamBayes Score 1.26673e-05
Marked as misclassified No
Message-id <>
That's one of the nicer attempts I've seen at an object-oriented path library, but I have a core problem with OOP path APIs, and it relates to the Unicode encoding/decoding problem: the ultimate purpose of path objects is almost always to either pass them to the OS, or else to another application. That exchange will almost *always* happen as a plain string.

So when your approach is based on a more sophisticated type internally, you end up having to be very careful about all of your system boundaries, making sure that "paths" are correctly being turned into "Paths".

However, one of my hopes for iterwalk will be that it *won't* care if the underlying walk iterator produces Path objects instead of ordinary strings, so long as those objects can be passed to fnmatch, os, etc and work correctly.
Date User Action Args
2011-11-06 01:25:03ncoghlansetrecipients: + ncoghlan, pitrou, vstinner, eric.araujo
2011-11-06 01:25:03ncoghlansetmessageid: <>
2011-11-06 01:25:02ncoghlanlinkissue13229 messages
2011-11-06 01:25:01ncoghlancreate