Martin v. Löwis wrote: > That said, if the people who want a path object would get together > and contribute one, the library could be extended. I don't know > whether this would be an improvement, though - os.path could not > go away for backwards compatibility, so users would now have *two* > ways of dealing with path names.
That's true. But it indicates that the idea of a "standard library" or "batteries included" approach in Python which collects the most common and important computing ideas and expresses them in a mandatory Pythonic implementation is beginning to die or at least changes it's meaning into: an exposition library of the CPython interpreter which remains clearly indispensable. > I also think that one of the reasons why there isn't a path object > in the standard library yet is that nobody who has written one in > the past trusts his own code enough to make it "official". Jason > Orendorff writes "I find it a joy to use, and I hope you will too." > This is the standard open source attitude (and rightly so): if > you don't like it, don't use it. This attitude could not be > preserved anymore if this would be in the standard library (or > else we would not have this discussion). Jason Orendorff seems not to be the only one who finds it a "joy to use". > For a number of libraries added recently, I heard lots of complaints > how terrible they are to use, including, in particular, the XML > and logging libraries, and the Unicode type, and that "something > else" is so much easier to use. Why is it that the authors of > "something else" never contribute it to Python? You have already given the arguments in Your discussion above. I personally never use the standard-lib XML parser, but pyRXP/pyRXPU which is fast, stores objects in pythonic list/tuple/dict structures and provides access by lazy tagging, implemented in the small xmlutils.py module which I extended for my own comfort. It dispenses both the slow javaesque W3C-DOM parser implementation and the statemachine oriented SAX. But has this module some place in the standard-lib. No, because it promotes double implementation i.e. not only one way to do it. And throwing away old stuff is impossible because downwards incompatibilities. No one of these axioms can be skipped for a standard lib. So almost everyone deals with cute 3-rd party packages. Regards, Kay -- http://mail.python.org/mailman/listinfo/python-list