PEP on path module for standard library

[John Roth]

"Reinhold Birkenfeld" <reinhold-birkenfeld-nospam at wolke7.net> wrote in 
message news:3kakh5Ftjd9mU1 at individual.net...
> John Roth wrote:
>> "Michael Hoffman" <cam.ac.uk at mh391.invalid> wrote in message
>> news:dbofk2$g1f$1 at gemini.csx.cam.ac.uk...
>>> Many of you are familiar with Jason Orendorff's path module
>>> <http://www.jorendorff.com/articles/python/path/>, which is frequently
>>> recommended here on c.l.p. I submitted an RFE to add it to the Python
>>> standard library, and Reinhold Birkenfeld started a discussion on it in
>>> python-dev
>>> <http://mail.python.org/pipermail/python-dev/2005-June/054438.html>.
>>>
>>> The upshot of the discussion was that many python-dev'ers wanted path
>>> added to the stdlib, but Guido was not convinced and said it must have a
>>> PEP.
>>
>> Why did Guido want a PEP? Is it because he likes the idea but
>> feels the feature set needs to be examined a bit more by the wider
>> community, or is it some other reason?
>
> He said,
>
> """
> Whoa! Do we really need a completely different mechanism for doing the
> same stuff we can already do? The path module seems mostly useful for
> folks coming from Java who are used to the Java Path class. With the
> massive duplication of functionality we should also consider what to
> recommend for the future: will the old os.path module be deprecated,
> or are we going to maintain both alternatives forever? (And what about
> all the duplication with the os module itself, like the cwd()
> constructor?) Remember TOOWTDI.
> """

Read literally, this says (at least to me) "I don't want to fix it because
I don't think it's broke."

As far as the Java remark is concerned, I suspect that it's because
in Java there is no such thing as a function; everything is either a
method on an object or a static method on a class.

And as far as I'm concerned, it's broke. I could see getting rid of the
bits and  pieces of  procedural code in 3.0, but not sooner.

John Roth
>
> Reinhold