"Mike Orr" <sluggoster at gmail.com> wrote in message news:6e9196d20605040113x2a2d563ah23fabf02c49a0778 at mail.gmail.com... > 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
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4