"Mike Orr" <[EMAIL PROTECTED]> wrote in message news:[EMAIL PROTECTED] > Intriguing idea, Noam, and excellent thinking. I'd say it's worth a > separate PEP.
I am glad to see this idea resurface and developed. So +1 on an alternate PEP. > The main difficulty with this approach is it's so radical. Only locally. Last July, I wrote the following for clp: http://article.gmane.org/gmane.comp.python.general/412997 Subject: Re: PEP on path module for standard library Date: 2005-07-22 18:47:00 GMT " Very interesting. Java's File class is a system-independent "abstract representation of file and directory pathnames" which is constructed from and converted to system-dependent string-form pathnames (including URL/URI file:... forms). A File consist of an optional prefix and a *sequence* of zero or more string names. In other words, Java's File class is what Duncan and I thought Python's Path class might or possibly should be. So this internal representation might be worth considering as an option. Of course, if the interface is done right, it mostly should not make too much difference to the user. " I believe a previous post gave the reference to the File doc, which might be worth consulting. As I remember, the general response at that time was that the existing string-based path class was tried, useful, and well accepted, so why try anything more different. That seems to have become clearer with time. Terry Jan Reedy _______________________________________________ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
