No validation routine for an os.path

[Edward Diener]

Peter Hansen wrote:
> Edward Diener wrote:
>
>> Try as I might I can not find a routine in os.path which validates
>> whether or not a path is syntactically valid, either as a directory
>> or as a file. This is surprising since, although I know this is OS
>> dependent, Python has many other classes and functions which will
>> work properly depending on what OS they are currently running under.
>> Is there such a path validation routine in any of the libraries
>> distributed with Python or in any other 3rd party Python libraries ?
>
> I don't really think so, and the last time this sort of thing
> was discussed, I believe the conclusion was that it's not
> actually possible to do such a thing in all cases anyway,
> unless you are willing to actually attempt to create the
> file or directory during the validation.

Operating systems do have rules for what constitutes a valid file
specification and/or directory specification. Some even have API functions
which can be called to directly find out.

>
> One reason I recall being given is that even on a given OS, different
> file systems may support different sets of characters for filenames.
> For example, a CDROM might disallow certain characters which the
> standard file system allows, or a networked device (e.g. NFS, or
> Samba) might allow a wider range of possibilities than the permitted
> names on a hard drive.

You have a good point there. But with a file spec and a bit of work, one
should be able to tell what sort of drive is being accessed.

>
> In the end, this is somewhat like validating email addresses.  Until
> you actually try and succeed (or fail) to send the message, you cannot
> verify whether an address is "valid" for many definitions of valid.

I do not totally agree, especially as the OS will know whether something is
valid so it obviously has rules itself. But I grant it is more difficult
than might be assumed. BTW email addresses actually do have a format which
can be parsed ( RFC 822 originally ), although again it is complicated.