Peter Hansen wrote: > Okay, granted. I guess this is the same as in any other case of > deprecation (e.g. some people still have to work with code that uses > apply() or string module methods).
Yup, this is exactly what will have to happen. Most or all of os.path and maybe some of os/glob/fnmatch/stat will have to be deprecated and kept around for a release or two. Perhaps a large section of the PEP-to-come should deal with this. > > Peter Hansen: > >> We've mandated use of path.py internally for all projects because > >> we've noticed (especially with non-expert Python programmers... i.e. > >> junior and intermediate types, and senior types new to Python) a > >> decrease in errors. My personal experience has always been that when it comes time to write the part of the project that interacts with the filesystem, I have to decide once again if I want to use the standard library, or use path.py. And I usually decide against using path.py; not because I don't like it, but because I don't like bundling code that I didn't write as part of my project. A lot of the programs that I write in python are pretty simple single file scripts that help manage machines on an intranet. I like to be able to simply copy these scripts around and run them without worrying about their dependencies. Another personal observation is that the current os.path / fnmatch / glob / stat modules give a very C-like interface to the filesystem. There's a lot of repetition of things like os.path.join(), os.path.splitext(), as well as repetition of the reference to the string object which defines the path being operated on. This seems to violate the DRY principle to a small degree, and it also makes code that much harder to maintain. Cheers, Chris -- http://mail.python.org/mailman/listinfo/python-list
