[Python-Dev] The path module PEP

[BJörn Lindqvist]

My comments on the issues. It was easier this way than trying to reply
on every message individually.

Inheritance from string (Jason)

This issue has been brought up before when people were discussing the
path module. I think the consensus is that, while the inheritance
isn't pure, practicality beats purity. It would require to big changes
to Python and would break to much existing code to not extend string.

I'll add this to Resolved Issues if nobody minds.

* http://mail.python.org/pipermail/python-dev/2001-August/016663.html
* http://mail.python.org/pipermail/python-dev/2001-August/016665.html
* http://mail.python.org/pipermail/python-list/2005-July/291091.html
* http://mail.python.org/pipermail/python-list/2005-July/291152.html


Remove __div__ (Ian, Jason, Michael, Oleg)

This is one of those where everyone (me too) says "I don't care either
way." If that is so, then I see no reason to change it unless someone
can show a scenario in which it hurts readability. Plus, a few people
have said that they like the shortcut.

* http://mail.python.org/pipermail/python-list/2005-July/292251.html
* http://mail.python.org/pipermail/python-dev/2005-June/054496.html
* http://mail.python.org/pipermail/python-list/2005-July/291628.html
* http://mail.python.org/pipermail/python-list/2005-July/291621.html


Remove redundant methods (Eric, Ian, Jason, Ronald, Toby)

I think it is a good idea to take out some of Path's
methods. Especially the ones that exist as both methods and
properties. I have updated the pep and dumped basename(), dirname(),
splitdrive() and splitext().  I think that glob() should also go away
because I can't of the top of my head think of a scenario where it
would be suitable over listdir(), dirs() or files(). Plus, for
contrived examples; like glob.glob("/*bin/*foo*") the Path way doesn't
look so good: Path("/").glob("*bin/*foo*").


Renaming methods because of PEP 8 (Gustavo, Ian, Jason)

I'm personally not keen on that. I like most of the names as they
are. abspath(), joinpath(), realpath() and splitall() looks so much
better than abs_path(), join_path(), real_path() and split_all() in my
eyes. If someone like the underscores I'll add it to Open Issues.


Removing open() and methods that manipulate the whole file at once
(Ian, Jason)

I think this is settled with the addition of the with statement? My
idea when scrubbing these methods was that it would make it easier to
get the PEP accepted. However, even with with, these methods save some
typing.

* http://mail.python.org/pipermail/python-dev/2005-June/054439.html
* http://mail.python.org/pipermail/python-list/2005-July/291435.html


?time properties and get?time() methods

Clearly, Path has either the properties or the methods, not both at
once. Yet another "I don't care either way."

* http://mail.python.org/pipermail/python-dev/2005-June/054439.html
* http://mail.python.org/pipermail/python-list/2005-July/291424.html
* http://mail.python.org/pipermail/python-list/2005-July/291460.html


I have also the corrected the copy-paste errors I inadvertedly
introduced. Path should *not* have an __iter__. :)

* match() and matchcase() wraps the fnmatch.fnmatch() and
  fnmatch.fnmatchcase() functions. I believe that the renaming is
  uncontroversial and that the introduction of matchcase() makes it so
  the whole fnmatch module can be deprecated.

I have created an implementation of Path that corresponds to the
specification in the PEP (which I hope will appear on
www.python.org/peps soon). It is based on Reinhold's (Georg Brandl)
implementation from pre-PEP threads in c.l.p last summer. But I have
no place to upload it. I would also like if some people wants to
co-author this PEP with me - it's really neither my PEP nor my module.

--
mvh Björn