Guido van Rossum writes:
Oops, sorry. The first one is proposing a validate() function for pathnames. In the second one, the patch code speaks for itself -- it
I did have a thought on this, but hadn't gotten back to it. Essentially, I'm not sure how to implement this correctly; things like MAXPATHLEN aren't always easy to root out the "right" way to get the *real* definition from C. pathconf(_PC_PATH_MAX) could be used to get that, and pathconf(_PC_NAME_MAX) can get the maximum length of an individual name within the path, but I don't know if the concepts are even meaningful on all systems. I wouldn't be surprised if validity on some systems is highly specific to the actual filesystem that's being referred to, and that requires the name be valid on the local system. I've noticed that the functions in the os.path implementations fall into two categories: "abstract" functions like join(), split(), and the like, which are bound to the "path algebra" syntax rules, and the "local-access" functions like isfile() and abspath(), which require the paths relate to the local system. This isn't a problem, but something we should probably keep in mind.
makes an exception class conform to the rule that exceptions must inherit from Exception.
I don't think this is valuable for 1.6, but might be interesting for 1.7; the documentation can include a notice that this relationship will be required in the future. That would allow people to define exceptions with the required inheritance before the last minute. On the other hand, I'm not sure it really matters that exceptions inherit from a specific base class. *That* seems unnecessary. -Fred -- Fred L. Drake, Jr. <fdrake at acm.org> Corporation for National Research Initiatives