Jason Orendorff wrote:
[...]omitted: * Function for opening a path - better handled by the builtin open().
Aside: I added this to support a few people who liked the idea of "openable objects", meaning anything that has .open(), analogous to "writeable objects" being anything with .write(). I don't use it personally.
Losing .open() would make it much harder for anyone wanting to write, say, a URI library that implements the Path API.
I suspect you'll be asked to change the PEP to remove __div__ for starters, in which case I propose using the Path constructor as the replacement for os.path.join(). In that case, Path.joinpath can be dropped.
I'm -1 on this too. This means people will be hardcoding the specific class they expect, so you can't pass in other classes. E.g., this will fail: def read_config(home_dir): f = open(Path(home_dir, '.config_file')) c = f.read() f.close() return c read_config(URI('http://localhost/foo')) I'm personally +1 on /. I think people who think it is confusing are giving a knee-jerk reaction. It's very easy to tell the difference between file-related code and math-related code, and / is currently only used for math. In contrast, + is used for concatenation and addition, and these are far more ambiguous from context -- but still it doesn't cause that many problems. But barring /, .joinpath() should remain. Too bad there isn't a shorter name, except .join() which is taken. I would also, though, note that there are some security issues. When you use open() or other path-related functions, you *know* you are doing filesystem operations. You can't be getting some weird object that does who-knows-what. For the most part if you can get an arbitrary object into the system then the system is just broken, but I can imagine cases where this encourages people to do bad things. I only bring this up because it reminds me of PHP allowed over-the-net includes, which always seemed like a bad idea. -- Ian Bicking / ianb@colorstudy.com / http://blog.ianbicking.org