[Python-Dev] Python 1.6 timing

[Guido van Rossum]

> 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 personally think there is very little merit in a validate() function
-- it's not going to be a very useful predictor of whether an open may
succeed or not.

>   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.

This is valuable mostly as an example; plus in that specific case I
think he noticed that the module defines an exception class from
scratch with functionality that is already present in the standard
Exception class.

--Guido van Rossum (home page: http://www.python.org/~guido/)