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 _______________________________________________ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
