Reinhold Birkenfeld wrote: > Mike Orr wrote: >>- Who needs .open()? open(myPath) is fine. But it can stay for >>backward compatibility. > > Right. I think it's nice for people who like a more OO approach.
There's one very good reason to use .open() on a Path object, and in fact it's a (for me) strong justification for the existence of Path in the standard library (and, even more, for porting everything else in the standard library to use Path). A scattered assortment of module-level global function names, and builtins such as open(), make it extraordinarily difficult to do effective and efficient automated testing with "mock" objects. Although one can fairly easily shadow the definition of "open" in any given module under test, if the code under test instead calls another standard library routine which internally uses open(), it becomes necessary to replace the builtin definition of open() and affect all code throughout the program. Object-oriented solutions like Path make it near trivial to substitute a mock or other specialized object which (duck typing) acts like a Path except perhaps for actually writing the file to disk, or whatever other difference you like. I haven't gotten around to doing a mock Path object yet, though given the work that's gone into my existing mock FileSystem object which lets you replace open() and test code in a fully controlled and safe environment, it shouldn't be hard to do. So, for the PEP, another justification for Path is that its use can encourage better use of automated testing techniques and thereby improve the quality of Python software, including in the standard library. -Peter -- http://mail.python.org/mailman/listinfo/python-list
