[Python-Dev] The path module PEP

Hello BJörn, Like you I've used the Path module one time or another. It is an excellent concept to refactor the confusing collection of file handling methods. I have not used it consistently, mainly because the module has not been maintained and it is not in the standard library as it shoul

Re: [Python-Dev] The path module PEP

On 1 feb 2006, at 19:14, BJörn Lindqvist wrote: > I've submitted an updated version of the PEP. The only major change is > that instead of the method atime and property getatime() there is now > only one method named atime(). Also some information about the string > inheritance problem in Open Iss

Re: [Python-Dev] The path module PEP

I've submitted an updated version of the PEP. The only major change is that instead of the method atime and property getatime() there is now only one method named atime(). Also some information about the string inheritance problem in Open Issues. I still have no idea what to do about it though. --

Re: [Python-Dev] The path module PEP

on 27.01.2006 11:16 Paul Moore said the following: > [...] >>> Arguably, Path objects should always maintain an absolute path - there >>> should be no such thing as a relative Path. So you would have >> you realise that one might need and/or want to represent a relative path? > > Absolutely. But n

Re: [Python-Dev] The path module PEP

On 1/26/06, Stefan Rank <[EMAIL PROTECTED]> wrote: > on 26.01.2006 14:15 Paul Moore said the following: > [snip] > > > > Also note that my example Path("C:", "Windows", "System32") above is > > an *absolute* path on Windows. But a relative (albeit stupidly-named > > :-)) path on Unix. How would tha

Re: [Python-Dev] The path module PEP

Michael Hoffman wrote: > I've been using path.py for some time, and I can tell you that it > would be a lot less useful if it no longer behaved like string-plus. As Jason pointed out elsewhere, the strict typechecks that exist *in* the Python core, and the fact that path.py is *outside* that core

Re: [Python-Dev] The path module PEP

One other benefit that I neglected to put into the previous post - I was able to maintain separate cwd's for each tree. An example of use: Each tree has its own context, independent of the context of python: >>> local, local2 = fs.LocalTree(), fs.LocalTree() >>> local.pwd '/home/targoz' >>>

Re: [Python-Dev] The path module PEP

The path module has a great idea, but it does too much -- it conflates too many ideas into a single module. It has methods for dealing with files (open, bytes, read, etc) as well as methods for dealing with a filesystem tree as a whole (relpath, abspath, etc). Both of these ideas are tangent

Re: [Python-Dev] The path module PEP

On Thu, 2006-01-26 at 16:17 +0100, Fredrik Lundh wrote: > Gustavo J. A. M. Carneiro wrote: > > > > If a URI class implemented the same methods, it would be something of a > > > question whether uri.joinpath('/foo/bar', 'baz') would return '/foo/baz' > > > (and urlparse.urljoin would) or '/foo/bar/

Re: [Python-Dev] The path module PEP

on 26.01.2006 16:34 Aaron Bingham said the following: > Stefan Rank wrote: >> on 26.01.2006 14:15 Paul Moore said the following: >> [snip] >> >>> Arguably, Path objects should always maintain an absolute path - there >>> should be no such thing as a relative Path. >>> >> you realise that one might

Re: [Python-Dev] The path module PEP

Stefan Rank wrote: >on 26.01.2006 14:15 Paul Moore said the following: >[snip] > > >>Arguably, Path objects should always maintain an absolute path - there >>should be no such thing as a relative Path. So you would have >> >> > >you realise that one might need and/or want to represent a rela

Re: [Python-Dev] The path module PEP

Gustavo J. A. M. Carneiro wrote: > > If a URI class implemented the same methods, it would be something of a > > question whether uri.joinpath('/foo/bar', 'baz') would return '/foo/baz' > > (and urlparse.urljoin would) or '/foo/bar/baz' (as os.path.join does). > > I assume it would be be the latte

Re: [Python-Dev] The path module PEP

on 26.01.2006 14:15 Paul Moore said the following: [snip] > > Also note that my example Path("C:", "Windows", "System32") above is > an *absolute* path on Windows. But a relative (albeit stupidly-named > :-)) path on Unix. How would that be handled? wrong, Path("C:", "Windows", "System32") is a r

Re: [Python-Dev] The path module PEP

[Thomas Wouters] >>> [Subclassing string] is my only problem with the PEP. It's all very nice >>> that subclassing from string makes it easier not to break things, but >>> subclassing implies a certain relationship. [Michael Hoffman] >> This is the soul of arguing for purity's sake when practicali

Re: [Python-Dev] The path module PEP

On Thu, Jan 26, 2006 at 09:26:27AM +, Michael Hoffman wrote: > [Thomas Wouters] > > [Subclassing string] is my only problem with the PEP. It's all very nice > > that subclassing from string makes it easier not to break things, but > > subclassing implies a certain relationship. > This is the s

Re: [Python-Dev] The path module PEP

On 1/25/06, BJörn Lindqvist <[EMAIL PROTECTED]> wrote: > 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 c

Re: [Python-Dev] The path module PEP

On 1/26/06, Thomas Wouters <[EMAIL PROTECTED]> wrote: > On Wed, Jan 25, 2006 at 09:37:04PM +0100, BJörn Lindqvist wrote: > > > 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 inheri

Re: [Python-Dev] The path module PEP

On Wed, 2006-01-25 at 22:35 -0600, Ian Bicking wrote: > Gustavo J. A. M. Carneiro wrote: > > On a slightly different subject, regarding path / path, I think it > > feels much more natural path + path. Path.join is really just a string > > concatenation, except that it adds a path separator in th

Re: [Python-Dev] The path module PEP

[Thomas Wouters] >> 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

Re: [Python-Dev] The path module PEP

On Wed, 2006-01-25 at 22:30 -0600, Ian Bicking wrote: > IMHO the hierarchy problem is a misdesign of strings; iterating over > strings is usually a bug, not a deliberately used feature. And it's a > particularly annoying bug, leading to weird results. Agreed. I've written iteration code that

Re: [Python-Dev] The path module PEP

Gustavo J. A. M. Carneiro wrote: > On a slightly different subject, regarding path / path, I think it > feels much more natural path + path. Path.join is really just a string > concatenation, except that it adds a path separator in the middle if > necessary, if I'm not mistaken. No, it isn't, w

Re: [Python-Dev] The path module PEP

Barry Warsaw wrote: > On Wed, 2006-01-25 at 18:10 -0600, Ian Bicking wrote: > > >>Paths are strings, that's in the PEP. >> >>As an aside, I think it should be specified what (if any) string methods >>won't be inherited by Path (or will be specifically disabled by making >>them throw some except

Re: [Python-Dev] The path module PEP

On Wed, 2006-01-25 at 18:10 -0600, Ian Bicking wrote: > Paths are strings, that's in the PEP. > > As an aside, I think it should be specified what (if any) string methods > won't be inherited by Path (or will be specifically disabled by making > them throw some exception). I think .join() and

Re: [Python-Dev] The path module PEP

[Gustavo J. A. M. Carneiro] > Plus, the names are full of redundancy. Why abspath(), joinpath(), > realpath(), splitall()? Why not instead: absolute(), join(), real(), > split() ? Remember that they are all methods of a Path class, you > don't > need to keep repeating 'path' all over the place

Re: [Python-Dev] The path module PEP

[Ian Bicking] > Paths are strings, that's in the PEP. No, the PEP says that Path is a *subclass* of string ("Path extends from string"). In addition, it's a disputed part of the PEP (see elsewhere in this thread). =Tony.Meyer ___ Python-Dev mailing

Re: [Python-Dev] The path module PEP

On Wed, Jan 25, 2006 at 09:37:04PM +0100, BJörn Lindqvist wrote: > 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

Re: [Python-Dev] The path module PEP

On Wed, 2006-01-25 at 21:37 +0100, BJörn Lindqvist wrote: > 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(), re

Re: [Python-Dev] The path module PEP

[Charles Cazabon] > It screams "magic" in a very un-Pythonic (and possibly very > Perl-like) way. I'm not aware of any other part of the standard > library grossly abusing standard operators in this way. I think the use of the modulo operator for string substitution is pretty comparable, despite

Re: [Python-Dev] The path module PEP

Tony Meyer wrote: > [Ian Bicking] > >> If it were possible to use .join() for joining paths, I think I >> wouldn't mind so much. But reusing a string method for something >> very different seems like a bad idea. So we're left with .joinpath >> (). Still better than os.path.join() I guess,

Re: [Python-Dev] The path module PEP

On Thu, 26 Jan 2006, Tony Meyer wrote: [...] > Why does reusing a string method for something very different seem > like a bad idea, but reusing a mathematical operator for something > very different seem like a good idea? [...] That's easy -- it's because, if you're going to use a name, peopl

Re: [Python-Dev] The path module PEP

On Jan 25, 2006, at 3:42 PM, Tony Meyer wrote: > [Ian Bicking] >> If it were possible to use .join() for joining paths, I think I >> wouldn't mind so much. But reusing a string method for something >> very different seems like a bad idea. So we're left with .joinpath >> (). Still better than os

Re: [Python-Dev] The path module PEP

[Ian Bicking] > If it were possible to use .join() for joining paths, I think I > wouldn't mind so much. But reusing a string method for something > very different seems like a bad idea. So we're left with .joinpath > (). Still better than os.path.join() I guess, but only a little. > I g

Re: [Python-Dev] The path module PEP

BJörn Lindqvist wrote: > 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

Re: [Python-Dev] The path module PEP

Phillip J. Eby <[EMAIL PROTECTED]> wrote: > > I'd also note that using the / operator seems to me to be a big win on > "beautiful is better than ugly". It screams "magic" in a very un-Pythonic (and possibly very Perl-like) way. I'm not aware of any other part of the standard library grossly abus

Re: [Python-Dev] The path module PEP

Tony Meyer wrote: >>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

Re: [Python-Dev] The path module PEP

At 11:25 AM 1/26/2006 +1300, Tony Meyer wrote: >Against it: > > * Zen: Beautiful is better than ugly. Explicit is better than >implicit. Readability counts. There should be one-- and preferably >only one --obvious way to do it. > > * Not every platform that Python supports has '/' as the path >

Re: [Python-Dev] The path module PEP

> 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 shor

Re: [Python-Dev] The path module PEP

On Tue, 24 Jan 2006, Ian Bicking wrote: [...] > Losing .open() would make it much harder for anyone wanting to write, > say, a URI library that implements the Path API. [...] Why? Could you expand a bit? What's wrong with urlopen(filesystem_path_instance) ? John __

Re: [Python-Dev] The path module PEP

[Ian Bicking] >Losing .open() would make it much harder for anyone wanting to write, >say, a URI library that implements the Path API. [John] > Why? Could you expand a bit? > > What's wrong with urlopen(filesystem_path_instance) ? [Ian] >def read_config(path): >text = path.open().r

Re: [Python-Dev] The path module PEP

John J Lee wrote: > On Tue, 24 Jan 2006, Ian Bicking wrote: > [...] > >>Losing .open() would make it much harder for anyone wanting to write, >>say, a URI library that implements the Path API. > > [...] > > Why? Could you expand a bit? > > What's wrong with urlopen(filesystem_path_instance) ?

Re: [Python-Dev] The path module PEP

BJörn Lindqvist wrote: > * 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. The renaming is fine with

Re: [Python-Dev] The path module PEP

On Wed, Jan 25, 2006 at 09:37:04PM +0100, BJ?rn Lindqvist wrote: > Remove __div__ (Ian, Jason, Michael, Oleg) I didn't say "remove". Exactly opposite - I am enamoured by the beauty of the syntax! (-: Oleg. -- Oleg Broytmannhttp://phd.pp.ru/[EMAIL PROTECTED]

Re: [Python-Dev] The path module PEP

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 be

Re: [Python-Dev] The path module PEP

On 1/24/06, Ian Bicking <[EMAIL PROTECTED]> wrote: > There's kind of a lot of methods in here, which is a little bothersome. > It also points towards the motivation for the class -- too many > options in too many places in the stdlib. But throwing them *all* in > one class consolidates but doesn't

Re: [Python-Dev] The path module PEP

On 1/25/06, Toby Dickenson <[EMAIL PROTECTED]> wrote: > On Tuesday 24 January 2006 20:22, BJörn Lindqvist wrote: > > #Replacing glob.glob > > glob.glob("/lib/*.so") > > ==> > > Path("/lib").glob("*.so") > > This definition seems confusing because it splits the glob pattern string in

Re: [Python-Dev] The path module PEP

On Tuesday 24 January 2006 20:22, BJörn Lindqvist wrote: > Replacing glob.glob > --- > > glob.glob("/lib/*.so") > ==> > Path("/lib").glob("*.so") This definition seems confusing because it splits the glob pattern string in two ('/lib', and '*.so'). Unless the

Re: [Python-Dev] The path module PEP

[Tony Meyer] > It would be great (and save a lot of rehashing) if you could go over > the python-dev discussion and add the relevant parts (for example, > whether to include the __div__ hack) to the PEP: > > In particular the poi

Re: [Python-Dev] The path module PEP

[Ian Bickling] > I'm personally +1 on /. I think people who think it is confusing are > giving a knee-jerk reaction. It's very easy to tell the difference > between file-related code and math-related code, and / is currently only > used for math. In contrast, + is used for concatenation and add

Re: [Python-Dev] The path module PEP

There's kind of a lot of methods in here, which is a little bothersome. It also points towards the motivation for the class -- too many options in too many places in the stdlib. But throwing them *all* in one class consolidates but doesn't simplify, especially with duplicate functionality.

Re: [Python-Dev] The path module PEP

Gustavo J. A. M. Carneiro wrote:. >>def splitall(self): ... >>def relpath(self): ... >>def relpathto(self, dest): ... > > [...etc...] > > If we wanted to take PEP 8 seriously, those method names should be > changed to words_separated_by_underscores. There's a (unspecifi

Re: [Python-Dev] The path module PEP

Gustavo J. A. M. Carneiro wrote: > > # Operations on path strings. > > def abspath(sef): ... > > def normcase(self): ... > > def normpath(self): ... > > def realpath(self): ... > > def expanduser(self): ... > > def expandvars(self): ... > >

Re: [Python-Dev] The path module PEP

> The last time this was discussed six months ago it seemed like most of > python-dev fancied Jason Orendorff's path module. But Guido wanted a > PEP and noone created one. So I decided to claim the fame and write > one since I also love the path module. :) Much of it is copy-pasted > from Peter As

Re: [Python-Dev] The path module PEP

[Gustavo J. A. M. Carneiro wrote] > And BTW, what does splitunc do? http://en.wikipedia.org/wiki/Path_%28computing%29#Universal_Naming_Convention > It really should have a more descriptive name. No more that should "urllib" or "splitext". Trent -- Trent Mick [EMAIL PROTECTED] _

Re: [Python-Dev] The path module PEP

Ian Bicking wrote: > I'm -1 on this too. This means people will be hardcoding the specific > class they expect, so you can't pass in other classes. E.g., this will > fail: > >def read_config(home_dir): >f = open(Path(home_dir, '.config_file')) >c = f.read() >f.close

Re: [Python-Dev] The path module PEP

On Tue, 2006-01-24 at 21:22 +0100, BJörn Lindqvist wrote: [...] > # Operations on path strings. > def abspath(sef): ... > def normcase(self): ... > def normpath(self): ... > def realpath(self): ... > def expanduser(self): ... > def expandvars

Re: [Python-Dev] The path module PEP

On Tue, Jan 24, 2006 at 09:22:01PM +0100, BJ?rn Lindqvist wrote: > Path("foo") / "bar" / "baz" I really love this! But I am afraid it's too much a Unixism. (-: Oleg. -- Oleg Broytmannhttp://phd.pp.ru/[EMAIL PROTECTED] Programmers don't die, they

Re: [Python-Dev] The path module PEP

Ian Bicking wrote: > BJörn Lindqvist wrote: >> * Functions for reading and writing a whole file - better handled >> by file objects read() and write() methods. > > I would be disappointed to see this left out, because I get really tired > of this little dance: > >f = open(filename)

Re: [Python-Dev] The path module PEP

BJörn Lindqvist wrote: > * Functions for reading and writing a whole file - better handled > by file objects read() and write() methods. I would be disappointed to see this left out, because I get really tired of this little dance: f = open(filename) c = f.read() f.close()

Re: [Python-Dev] The path module PEP

Jason Orendorff wrote: >>[...]omitted: >>* Function for opening a path - better handled by the builtin >> open(). > > > Aside: I added this to support a few people who liked the idea of > "openable objects", meaning anything that has .open(), analogous to > "writeable objects" being

Re: [Python-Dev] The path module PEP

Charles Cazabon wrote: > BJörn Lindqvist <[EMAIL PROTECTED]> wrote: > >>1. Make all python files in the a directory executable: > > [...] > >>==> >>for f in Path('/usr/home/guido/bin'): >>f.chmod(0755) > > > Iterating over a path string to read the contents of t

Re: [Python-Dev] The path module PEP

Thanks for doing this. I'm not sure anyone that matters here is actually keen on path, but I guess we'll see. A few comments: On 1/24/06, BJörn Lindqvist <[EMAIL PROTECTED]> wrote: > The following points summarizes the design: > > - Path extends from string, therefore all code which expe

Re: [Python-Dev] The path module PEP

Good stuff. Some suggestions: > def joinpath(self, *args): ... I suggest append() or extend() as join*() sort of suggest join() as provided by strings, which does something quite different > def splitall(self): ... and this may renamed split(), as it is quite similar to split() a

Re: [Python-Dev] The path module PEP

BJörn Lindqvist <[EMAIL PROTECTED]> wrote: > > 1. Make all python files in the a directory executable: [...] > ==> > for f in Path('/usr/home/guido/bin'): > f.chmod(0755) Iterating over a path string to read the contents of the directory possibly pointed to by that

[Python-Dev] The path module PEP

The last time this was discussed six months ago it seemed like most of python-dev fancied Jason Orendorff's path module. But Guido wanted a PEP and noone created one. So I decided to claim the fame and write one since I also love the path module. :) Much of it is copy-pasted from Peter Astrand's PE