Re: [path-PEP] Path inherits from basestring again
Ron Adam wrote: PS. Could someone repost the links to the current pre-pep and the most recent module version so I can look at it closer look? Pre-pre-PEP: http://wiki.python.org/moin/PathClass Reinhold's version of the module is in Python CVS in nondist/sandbox/path. Jason Orendorff's version is at http://www.jorendorff.com/articles/python/path/. -- Michael Hoffman -- http://mail.python.org/mailman/listinfo/python-list
Re: [path-PEP] Path inherits from basestring again
phil hunt wrote: On Sun, 31 Jul 2005 09:48:45 +0200, Reinhold Birkenfeld [EMAIL PROTECTED] wrote: An improvement to what? To how the class is implemented, or to how it is used? No, the second function is cleaner and more readable than the first, IMHO. True, but the first function, at all of seven lines, is hardly complicated. I mean, if anyone couldn't understand it, they'd never make a programmer. If you mean the former, yes is it, due to the os.path module not providing a function that does this. If you mean the latter, I disagree, because I would then have to call it with something like: pn = normalizePath(Path(p), q) That's easily helped by s/tp = p/tp = Path(p)/. I have no idea what that comment means. That's short for replace 'tp = p' by 'tp = Path(p). sed-lingo ;) Reinhold -- http://mail.python.org/mailman/listinfo/python-list
Re: [path-PEP] Path inherits from basestring again
Delaney, Timothy (Tim) wrote: Hey - paths are special enough to warrant additional syntax, aren't they? I hope this is a joke :) -- Michael Hoffman -- http://mail.python.org/mailman/listinfo/python-list
Re: [path-PEP] Path inherits from basestring again
Ivan Van Laningham wrote: People can subclass Path and add it if they really want it. They can use Jason's original module. My position is that the PEP without this use of __div__ is (a) better as a standard module, and (b) improves the chance of the PEP being accepted. I disagree. Using __div__ to mean path concatenation is no worse than using __add__ to mean string concatenation, But '+' doesn't mean string concatenation, it means (calls the __add__ method) which when used with objects other than numeric types is usually an object join method. It only means string concatenation when used with string objects. In this case a path object is a string object that behaves somewhat like a list and somewhat like a string depending on how it's being accessed. Maybe a string class isn't the best way to store a path. It seems to me a list with string elements would work better. I'm not sure why it was ruled out. Maybe someone could clarify that for me. I think it's a mistake to define '+' literally to mean string concatenation. I believe the '/' will be considered a wart by many and a boon by others. If I'm right, there will be endless discussions over it if it's implemented. I'd rather not see that, so I'm still -1 concerning '/' for that reason among others. Cheers, Ron PS. Could someone repost the links to the current pre-pep and the most recent module version so I can look at it closer look? -- http://mail.python.org/mailman/listinfo/python-list
Re: [path-PEP] Path inherits from basestring again
On Sat, 30 Jul 2005 19:01:49 +0200, Reinhold Birkenfeld [EMAIL PROTECTED] wrote: phil hunt wrote: def normalizePath(p, *pathParts): Normalize a file path, by expanding the user name and getting the absolute path.. @param p [string] = a path to a file or directory @param pathParts [list of string] = optional path parts @return [string] = the same path, normalized p1 = os.path.abspath(os.path.expanduser(p)) if len(pathParts)0: allPathParts = [ p1 ] allPathParts.extend(pathParts) p1 = os.path.join(*allPathParts) p2 = os.path.abspath(p1) return p2 normalisePath=normalizePath # alternate spelling join=normalizePath # it works like os.path.join, but better To be honest I don't see the point of having a Path class. That's the way Java does it, and I find path handling in Java to be a lot more of a hassle than in Python. (Actually, most things are more of a hassle in Java, but that's another story). You see, with the Path class the above function could be written as def normalizePath(p, *pathParts): Normalize a file path, by expanding the user name and getting the absolute path.. @param p [Path] = a path to a file or directory @param pathParts [list of string/Path] = optional path parts @return [Path] = the same path, normalized tp = p.expanduser().abspath() return tp.joinwith(*pathParts).abspath() That's clearly an improvement, isn't it? An improvement to what? To how the class is implemented, or to how it is used? If you mean the former, yes is it, due to the os.path module not providing a function that does this. If you mean the latter, I disagree, because I would then have to call it with something like: pn = normalizePath(Path(p), q) and then I would have the problem that (pn) isn't a string so calling a function to write some data into the file at that filename would no longer work, i.e. this: writeFile(pn, someData) would become this: writeFile(pn.getString(), someData) I don't see what having a Path type buys me. -- Email: zen19725 at zen dot co dot uk -- http://mail.python.org/mailman/listinfo/python-list
Re: [path-PEP] Path inherits from basestring again
phil hunt wrote: On Sat, 30 Jul 2005 19:01:49 +0200, Reinhold Birkenfeld [EMAIL PROTECTED] wrote: phil hunt wrote: def normalizePath(p, *pathParts): Normalize a file path, by expanding the user name and getting the absolute path.. @param p [string] = a path to a file or directory @param pathParts [list of string] = optional path parts @return [string] = the same path, normalized p1 = os.path.abspath(os.path.expanduser(p)) if len(pathParts)0: allPathParts = [ p1 ] allPathParts.extend(pathParts) p1 = os.path.join(*allPathParts) p2 = os.path.abspath(p1) return p2 normalisePath=normalizePath # alternate spelling join=normalizePath # it works like os.path.join, but better To be honest I don't see the point of having a Path class. That's the way Java does it, and I find path handling in Java to be a lot more of a hassle than in Python. (Actually, most things are more of a hassle in Java, but that's another story). You see, with the Path class the above function could be written as def normalizePath(p, *pathParts): Normalize a file path, by expanding the user name and getting the absolute path.. @param p [Path] = a path to a file or directory @param pathParts [list of string/Path] = optional path parts @return [Path] = the same path, normalized tp = p.expanduser().abspath() return tp.joinwith(*pathParts).abspath() That's clearly an improvement, isn't it? An improvement to what? To how the class is implemented, or to how it is used? No, the second function is cleaner and more readable than the first, IMHO. If you mean the former, yes is it, due to the os.path module not providing a function that does this. If you mean the latter, I disagree, because I would then have to call it with something like: pn = normalizePath(Path(p), q) That's easily helped by s/tp = p/tp = Path(p)/. and then I would have the problem that (pn) isn't a string so calling a function to write some data into the file at that filename would no longer work, i.e. this: writeFile(pn, someData) would become this: writeFile(pn.getString(), someData) Why? A Path is a string. Reinhold -- http://mail.python.org/mailman/listinfo/python-list
RE: [path-PEP] Path inherits from basestring again
Yes, I read and understood it. Saying Don't read this if you don't want to be offended doesn't make an offensive statement inoffensive. No, but it makes complaining that it was offensive pointless. I grant that Python is much easier to learn than other programming languages; students can pick up the basics rapidly. Once the basics are mastered and mentoring is over, reliance on guess and intuition is not a substitute for documentation, or for reading the code if documentation is not available. Working with paths *is* the basics, especially since another strength of Python is as a form of shell script. However, if the intention here is to create something different from Jason's original module, create something different and call it by another name than path; don't attempt to guess what Jason really meant. It is not Pythonic to guess. I believe the intent here is to add an OO path object to the standard library. If the intent was to add Jason's path module to the standard library, then there would be no room for discussion about how it was. No doubt Reinhold can clarify the intent here. Certainly there will be times when what is suitable for a third-party module is not suitable for a standard library module. =Tony.Meyer -- http://mail.python.org/mailman/listinfo/python-list
RE: [path-PEP] Path inherits from basestring again
Is classic Macintosh OS still supported on Python? No. At least, AFAIK, there is no intent to produce packages of new Python versions for Mac pre OS X. Old versions of Python still work, of course, but whatever version of Path makes it into Python (if any) is extremely unlikely to be supported on pre OS X Mac. I agree with all that you said, however :) =Tony.Meyer -- http://mail.python.org/mailman/listinfo/python-list
RE: [path-PEP] Path inherits from basestring again
I agree. It's yuck. So don't use it. If it were that simple, I wouldn't have bothered bringing it up. I really do believe this is a case of There should be one-- and preferably only one --obvious way to do it (as well as Explicit is better than implicit and Readability counts). If it's there, people will use it, and that means that people will have to know about it to understand that it means join and not divide (as some will expect). They'll to choose whether to use it (be explicit) or not, where the only one obvious way would remove the need for the choice. One could argue that since Although practicality beats purity and Although that way may not be obvious at first unless you're Dutch also apply here, although the latter will require Guido's answer, of course. =Tony.Meyer -- http://mail.python.org/mailman/listinfo/python-list
RE: [path-PEP] Path inherits from basestring again
While people are loathe to admit it, many stereotypes have some basis in fact. The problem is when people extend that to generalize about others (especially in a negative way). The intent was to use the basis-in-fact stereotype without having to explain in detail the factual basis, which didn't seem particularly useful, nor necessary. I suppose that was wrong. Since *I* am a Windows user and developer, if it was insulting, I was also insulting myself. For one person, at least, it seems that I needed to explain everything in as much detail as you did. Thanks for doing it for me :) [...] That being said, there is a big difference between a Windows *user* and a Windows *developer*. I doubt many Windows *users* will be writing Python code. Python is a great language for beginners (look at the tutor list). The language should be kept as easy as possible for beginners to use, while not limiting what experts can do (something to this effect was even said on python-dev recently). Lacking this __div__ hack doesn't limit experts, and does make it more difficult for beginners. =Tony.Meyer -- http://mail.python.org/mailman/listinfo/python-list
RE: [path-PEP] Path inherits from basestring again
Above all, nobody can tell me that there's any programmer who doesn't instantly recognize '/' as a directory separator. There is a programmer who doesn't instantly recognise '/' as a directory separator. I teach programming. The above is true. I think that the statement any programmer would instantly recognise '/' as division (and associate it therewith) is much more likely to be true. =Tony.Meyer -- http://mail.python.org/mailman/listinfo/python-list
RE: [path-PEP] Path inherits from basestring again
I have to say, the examples of using / don't really suggest path concatenation to me. However, I think the problem is the use of whitespace. Specifically:: path = Path() subdir = subdir f = filname path = path / subdir / f looks more like division (even with the obvious names I've used). OTOH: path = path/subdir/f *does* look a lot more like path concatenation. So for some people it may be how it is used. On the gripping hand, the second example reads more like a regex to me ... ;) OK - now for the silly suggestions ... I'm feeling tired ... methinks Guido would not be happy if I suggested the following on python-dev ;) For a relative path: path = ./subdir/f path = ../subdir/f For an absolute path: path = /dir/f Both of these are currently syntax errors. Introduce the . and .. syntax which map to calls to Path() and Path(os.path.dirname(os.cwd()) respectively, and the unary division operator (which can either preceed or follow the object). Hey - paths are special enough to warrant additional syntax, aren't they? Tim Delaney -- http://mail.python.org/mailman/listinfo/python-list
Re: [path-PEP] Path inherits from basestring again
On Sun, 31 Jul 2005 09:48:45 +0200, Reinhold Birkenfeld [EMAIL PROTECTED] wrote: An improvement to what? To how the class is implemented, or to how it is used? No, the second function is cleaner and more readable than the first, IMHO. True, but the first function, at all of seven lines, is hardly complicated. I mean, if anyone couldn't understand it, they'd never make a programmer. If you mean the former, yes is it, due to the os.path module not providing a function that does this. If you mean the latter, I disagree, because I would then have to call it with something like: pn = normalizePath(Path(p), q) That's easily helped by s/tp = p/tp = Path(p)/. I have no idea what that comment means. and then I would have the problem that (pn) isn't a string so calling a function to write some data into the file at that filename would no longer work, i.e. this: writeFile(pn, someData) would become this: writeFile(pn.getString(), someData) Why? A Path is a string. Aha, having read about path on the web, I know that now. I also withdraw my objections; it looks like it could well have been useful on some of the projects I've worked on. -- Email: zen19725 at zen dot co dot uk -- http://mail.python.org/mailman/listinfo/python-list
Re: [path-PEP] Path inherits from basestring again
Ivan Van Laningham wrote: Hi All-- Tony Meyer wrote: So far, there have been various statements that look like +0 for __div__, but no-one with a +1. (And I've said this a couple of times now, which really is just trolling for a +1 from someone). It's not a question of saving characters, but readability which, as you've said, is a matter of opinion. I like / as a shortcut to joinwith(). I like it a lot. I like it so much I'll give you a +2. Add a +1 from me. (Those who are offended by sweeping generalisations should ignore this next bit) I think it's also worth considering that Windows users are more clueless than users of posix systems. The readability of __div__ comes from familiarity with posix filesystems; for a Windows user, \ would be the natural character. So we're making things more readable for users that are already more likely figure things out, and less readable for users that have trouble figuring things out. This is not only bullshit, it's elitist bullshit. Windows users are more clueless than users of posix systems. Pfui. Prove it or withdraw it. Above all, nobody can tell me that there's any programmer who doesn't instantly recognize '/' as a directory separator. Reinhold -- http://mail.python.org/mailman/listinfo/python-list
Re: [path-PEP] Path inherits from basestring again
Hi All-- Tony Meyer wrote: (Those who are offended by sweeping generalisations should ignore this next bit) [...generalisation bit snipped...] This is not only bullshit, it's elitist bullshit. Windows users are more clueless than users of posix systems. Pfui. Prove it or withdraw it. Sigh. I guess you didn't read or understand the first sentence? Yes, I read and understood it. Saying Don't read this if you don't want to be offended doesn't make an offensive statement inoffensive. This (readability without knowing the language/standard libraries) is a huge benefit of using Python. It's overrated. It must be macho to say I learned Python without reading books. No it is not. Have you used Python as pseudocode when teaching people how to program? Many people have. That's just one example. I grant that Python is much easier to learn than other programming languages; students can pick up the basics rapidly. Once the basics are mastered and mentoring is over, reliance on guess and intuition is not a substitute for documentation, or for reading the code if documentation is not available. People can subclass Path and add it if they really want it. They can use Jason's original module. My position is that the PEP without this use of __div__ is (a) better as a standard module, and (b) improves the chance of the PEP being accepted. I disagree. Using __div__ to mean path concatenation is no worse than using __add__ to mean string concatenation, and it is both easy to remember (once the manual is read) and easy to type. Requiring users who want / to mean what it has always meant in the path module is neither easy nor intuitive. On the face of it, Jason would seem to agree, since he created / as a synonym for joinpath(). However, if the intention here is to create something different from Jason's original module, create something different and call it by another name than path; don't attempt to guess what Jason really meant. It is not Pythonic to guess. Metta, Ivan -- Ivan Van Laningham God N Locomotive Works http://www.andi-holmes.com/ http://www.foretec.com/python/workshops/1998-11/proceedings.html Army Signal Corps: Cu Chi, Class of '70 Author: Teach Yourself Python in 24 Hours -- http://mail.python.org/mailman/listinfo/python-list
Re: [path-PEP] Path inherits from basestring again
On Fri, 29 Jul 2005 14:38:23 +1200, Tony Meyer [EMAIL PROTECTED] wrote: def functions_which_modifies_some_file_in_place(path): output = open(path+'.tmp', 'w') . I dont want a seperator inserted between path and the new extension. Fair enough. Forget using '+' for join, then (which I was never that keen on - TIOWTDI), but I'm still -1 on using '/' for join. I agree. It's yuck. What's wrong with simply having each path-element as an argument to a function, e.g. join(foo, bar, baz) -- Email: zen19725 at zen dot co dot uk -- http://mail.python.org/mailman/listinfo/python-list
Re: [path-PEP] Path inherits from basestring again
On Fri, 29 Jul 2005 14:48:55 +1200, Tony Meyer [EMAIL PROTECTED] wrote: Would you really choose this: p = Path() / build / a / very / very / long / path Over this: p = Path(os.path.join(build, a, very, very, long, path)) Or have the constructor accept multiple arguments. ? A saving of six characters, and the second one is a lot clearer. If there was a os.path.joinPath (or whatever name) function that returned a Path object rather than a string, then you'd get: p = joinPath(build, a, very, very, long, path) Indeed. I have a little function I've written called normalizePath(). It expands users (~ and ~someuser), does os.path.join(), then gets the absolute path (os.path.abspath()) of the result. The code is trivial: def normalizePath(p, *pathParts): Normalize a file path, by expanding the user name and getting the absolute path.. @param p [string] = a path to a file or directory @param pathParts [list of string] = optional path parts @return [string] = the same path, normalized p1 = os.path.abspath(os.path.expanduser(p)) if len(pathParts)0: allPathParts = [ p1 ] allPathParts.extend(pathParts) p1 = os.path.join(*allPathParts) p2 = os.path.abspath(p1) return p2 normalisePath=normalizePath # alternate spelling join=normalizePath # it works like os.path.join, but better To be honest I don't see the point of having a Path class. That's the way Java does it, and I find path handling in Java to be a lot more of a hassle than in Python. (Actually, most things are more of a hassle in Java, but that's another story). -- Email: zen19725 at zen dot co dot uk -- http://mail.python.org/mailman/listinfo/python-list
Re: [path-PEP] Path inherits from basestring again
On Sat, 30 Jul 2005 14:10:52 +0200, Reinhold Birkenfeld wrote: Above all, nobody can tell me that there's any programmer who doesn't instantly recognize '/' as a directory separator. Is classic Macintosh OS still supported on Python? Because Mac programmers who haven't made the jump to OS X will probably instantly recognise ':' as the directory separator, not '/'. Acorn RISC OS developers may also instantly recognise '.' as the directory separator. And presumably mathematicians and numeric programmers who do very little file input/output will probably instantly recognise '/' as the division operator. And I have no idea what directory separators are in use under file systems that don't use ASCII or any extension to ASCII, eg the OS which has been described as the most common operating system in the world, the Japanese Real-time Operating System Nucleus, TRON. (Chances are you have at least half a dozen devices in your home with embedded TRON.) Still, your (modified) point that most Western programmers will quickly recognise '/' as a directory separator is surely true. Even given that, I'm not convinced that it is a good idea to turn '/' into a join-path operator. I don't have any good reasons for objecting either, just a funny little feeling in the back of my head that says that no good can ever come from allowing Path(C:\Windows)/cmd.com. -- Steven. -- http://mail.python.org/mailman/listinfo/python-list
Re: [path-PEP] Path inherits from basestring again
Ivan Van Laningham wrote: I like / as a shortcut to joinwith(). I like it a lot. I like it so much I'll give you a +2. +1 here. Extremely practical. -- Brian Beck Adventurer of the First Order -- http://mail.python.org/mailman/listinfo/python-list
Re: [path-PEP] Path inherits from basestring again
phil hunt wrote: On Fri, 29 Jul 2005 14:38:23 +1200, Tony Meyer [EMAIL PROTECTED] wrote: def functions_which_modifies_some_file_in_place(path): output = open(path+'.tmp', 'w') . I dont want a seperator inserted between path and the new extension. Fair enough. Forget using '+' for join, then (which I was never that keen on - TIOWTDI), but I'm still -1 on using '/' for join. I agree. It's yuck. So don't use it. What's wrong with simply having each path-element as an argument to a function, e.g. join(foo, bar, baz) Nothing's wrong, and you can do it this way too. Path(foo, bar, baz) or Path(foo).joinwith(bar, baz) Reinhold -- http://mail.python.org/mailman/listinfo/python-list
Re: [path-PEP] Path inherits from basestring again
phil hunt wrote: def normalizePath(p, *pathParts): Normalize a file path, by expanding the user name and getting the absolute path.. @param p [string] = a path to a file or directory @param pathParts [list of string] = optional path parts @return [string] = the same path, normalized p1 = os.path.abspath(os.path.expanduser(p)) if len(pathParts)0: allPathParts = [ p1 ] allPathParts.extend(pathParts) p1 = os.path.join(*allPathParts) p2 = os.path.abspath(p1) return p2 normalisePath=normalizePath # alternate spelling join=normalizePath # it works like os.path.join, but better To be honest I don't see the point of having a Path class. That's the way Java does it, and I find path handling in Java to be a lot more of a hassle than in Python. (Actually, most things are more of a hassle in Java, but that's another story). You see, with the Path class the above function could be written as def normalizePath(p, *pathParts): Normalize a file path, by expanding the user name and getting the absolute path.. @param p [Path] = a path to a file or directory @param pathParts [list of string/Path] = optional path parts @return [Path] = the same path, normalized tp = p.expanduser().abspath() return tp.joinwith(*pathParts).abspath() That's clearly an improvement, isn't it? Reinhold -- http://mail.python.org/mailman/listinfo/python-list
Re: [path-PEP] Path inherits from basestring again
Steven D'Aprano wrote: On Sat, 30 Jul 2005 14:10:52 +0200, Reinhold Birkenfeld wrote: Above all, nobody can tell me that there's any programmer who doesn't instantly recognize '/' as a directory separator. Is classic Macintosh OS still supported on Python? Because Mac programmers who haven't made the jump to OS X will probably instantly recognise ':' as the directory separator, not '/'. Acorn RISC OS developers may also instantly recognise '.' as the directory separator. I didn't say that '/' is the native directory separator on every platform. But other than ':' or '.', '/' is used as widely as URLs are, so it _will_ be recognizable as a directory separator. And presumably mathematicians and numeric programmers who do very little file input/output will probably instantly recognise '/' as the division operator. Yes, they will. But they presumably will read the documentation of the path module when using it (and, given that most operands will be strings, they won't suspect division going on). And I have no idea what directory separators are in use under file systems that don't use ASCII or any extension to ASCII, eg the OS which has been described as the most common operating system in the world, the Japanese Real-time Operating System Nucleus, TRON. (Chances are you have at least half a dozen devices in your home with embedded TRON.) Well, as long as Python doesn't run under TRON, that's not much of a point here. Still, your (modified) point that most Western programmers will quickly recognise '/' as a directory separator is surely true. Even given that, I'm not convinced that it is a good idea to turn '/' into a join-path operator. I don't have any good reasons for objecting either, just a funny little feeling in the back of my head that says that no good can ever come from allowing Path(C:\Windows)/cmd.com. Well, if you want to do such things, you surely don't need a path join anyway. Just write C:\\Windows\\ + something in this case. The path join is there for platform independence, and you will most certainly not write a Windows path directly into the source if you want to be XP compatible. Reinhold -- http://mail.python.org/mailman/listinfo/python-list
Re: [path-PEP] Path inherits from basestring again
On Sat, 2005-07-30 at 08:01 -0600, Ivan Van Laningham wrote: Tony Meyer wrote: (Those who are offended by sweeping generalisations should ignore this next bit) [...generalisation bit snipped...] This is not only bullshit, it's elitist bullshit. Windows users are more clueless than users of posix systems. Pfui. Prove it or withdraw it. Sigh. I guess you didn't read or understand the first sentence? Yes, I read and understood it. Saying Don't read this if you don't want to be offended doesn't make an offensive statement inoffensive. While people are loathe to admit it, many stereotypes have some basis in fact. The problem is when people extend that to generalize about others (especially in a negative way). It's probably true that, as a whole, most Windows users are quite a bit less knowledgeable about their systems than *nix users. This is probably the result of Windows being quite a bit more user-friendly than *nix systems (another generalization!), hence demanding less of the user, and also, I suspect, due to the fact that *nix users tend to be a self-selected crowd (they chose *nix because they wanted to learn more, and are willing to accept the larger demand the OS places on them in exchange for the added flexibility it provides). Of course, this is impossible to prove, but anyone who's done support knows where the majority of the silly questions come from. That being said, there is a big difference between a Windows *user* and a Windows *developer*. I doubt many Windows *users* will be writing Python code. I would expect that any Windows *programmer* would have no problem using / as a path delimiter (and in fact, Microsoft APIs have supported / as a path delimiter since MS-DOS days). Programmers are as much a self-selected crowd as the *nix users and this puts them on par with *nix developers. Using __div__ to mean path concatenation is no worse than using __add__ to mean string concatenation, and it is both easy to remember (once the manual is read) and easy to type. I agree. I like overloading as long as it makes sense when I read it. Python's use of + to mean concatenation doesn't make me blink, nor does overloading / in this case. In fact, I'm surprised it's only now been proposed. Regards, Cliff -- [EMAIL PROTECTED] http://www.develix.com :: Web applications and hosting :: Linux, PostgreSQL and Python specialists :: -- http://mail.python.org/mailman/listinfo/python-list
Re: [path-PEP] Path inherits from basestring again
[__div__ for .joinpath()] on 29.07.2005 04:48 Tony Meyer said the following: I, herewith, claim to have used it in the past. But I am indifferent as to if its needed, it just looks natural to me. So far there seem to have been a few +0s, but no +1s... What I use quite often is:: path(__file__).dirname() / somesiblingfileiknowisthere you do not have to think about trailing slashes or absolute vs. relative. and its much better than:: from os.path import * join(dirname(__file__), somesiblingfileiknowisthere) In what way is this much better? because of the 'object-orientedness'. i hope we agree on that (that's the reason for a path PEP?). the first is only sugar for the explicit:: path(__file__).dirname().joinpath(blablablabalbal) and as i said +0 operator overloading is only good if it's intuitive for the majority. (or Guido i suppose, in case this majority-person does not show up) [snip] Would you really choose this: p = Path() / build / a / very / very / long / path (Path() is the current dir I think) Over this: p = Path(os.path.join(build, a, very, very, long, path)) ? A saving of six characters, and the second one is a lot clearer. If there was a os.path.joinPath (or whatever name) function that returned a Path object rather than a string, then you'd get: p = joinPath(build, a, very, very, long, path) Which is better (clearer, more concise) than either of the others, IMO. actually for explicitness i would choose: (original jorendorff):: p = path(build).joinpath(any, path, you, can, imagine) or otherwise maybe:: p = path(alpha) / and / omega -- http://mail.python.org/mailman/listinfo/python-list
RE: [path-PEP] Path inherits from basestring again
[Tony Meyer] | | [Tim Golden] | Well, I actually had some correspondence with Jason on this | very subject a year or so ago: | [...] | Obviously, I don't know how much weight Jason's original | ideas have on the prepped-for-syslib module, but it does | support what other people have been saying: that the Path | should behave like a string where a string is expected. | | Was that the whole email? It certainly adds weight to '+' | having the normal | string behaviour, but it didn't really say anything about why | '/' should be | a shortcut for join. Do you know if Jason had any reasoning | for this other | than laziness wink? | | =Tony.Meyer Well, he did add the following paragraph: email For example: I haven't tried it, but I don't think the most obvious two-line fix will necessarily work. If you change __add__ to call os.path.join(), you'll likely get infinite recursion, because os.path.join() probably uses + to do its work. Of course this is pretty easy to work around; call it three lines. /email which might explain why he *didn't* use __add__ but doesn't explain whey he *did* use __div__. (There was more to the original email but that was more to do with some wild-eyed ideas I'd had about adding methods for file-locking and share-mounting to the path object). FWIW, my own feeling is that / is an awkward fit and relies for its ease-of-reading on the -- admittedly common but not universal -- use of that symbol as a path separator. I don't feel terribly strongly about it, but I don't tend to use it in my own code. TJG This e-mail has been scanned for all viruses by Star. The service is powered by MessageLabs. For more information on a proactive anti-virus service working around the clock, around the globe, visit: http://www.star.net.uk -- http://mail.python.org/mailman/listinfo/python-list
Re: [path-PEP] Path inherits from basestring again
Tony Meyer wrote: Would you really choose this: p = Path() / build / a / very / very / long / path Over this: p = Path(os.path.join(build, a, very, very, long, path)) I'd choose neither, because both are contrived examples (who builds paths out of six literals like that?) and the second one is not something anyone would want, since it mixes Paths and old-style os.path.join() calls. We're talking at this point about how Path should work, not whether it's preferable to os.path.join, even though that was really the point of Reinhard's original post. Given that, then, of the following two I would prefer the first one, slightly: p = somePath / user.getFolder() / 'archive' / oldPath + '.bak' p = somePath.joinpath(user.getFolder(), 'archive', oldPath + '.bak') ? A saving of six characters, and the second one is a lot clearer. It's not a question of saving characters, but readability which, as you've said, is a matter of opinion. I find the former more readable. Somewhat. Not enough to make a big deal about it. I can live with the latter, but as *someone who has used the path module already* I can only say that you might want to try it for a few months before condemning the approach using / as being unacceptable. -Peter -- http://mail.python.org/mailman/listinfo/python-list
RE: [path-PEP] Path inherits from basestring again
We're talking at this point about how Path should work, not whether it's preferable to os.path.join, even though that was really the point of Reinhard's original post. That's not what I'm talking about. I'm talking about whether __div__ should be a shortcut to joinwith, or whether users should be forced to use joinwith explicitly. So far, there have been various statements that look like +0 for __div__, but no-one with a +1. (And I've said this a couple of times now, which really is just trolling for a +1 from someone). It's not a question of saving characters, but readability which, as you've said, is a matter of opinion. (Those who are offended by sweeping generalisations should ignore this next bit) I think it's also worth considering that Windows users are more clueless than users of posix systems. The readability of __div__ comes from familiarity with posix filesystems; for a Windows user, \ would be the natural character. So we're making things more readable for users that are already more likely figure things out, and less readable for users that have trouble figuring things out. I can live with the latter, but as *someone who has used the path module already* I can only say that you might want to try it for a few months before condemning the approach using / as being unacceptable. 1. ISTM that standard library modules should be as readable as possible, even for those that don't use them. If I'm reading the source for module X and it uses a Path object, then it should be pretty straightforward to understand what is happening without also having to read the Path source/docs. This (readability without knowing the language/standard libraries) is a huge benefit of using Python. 2. If I did use the Path module, then I wouldn't use __div__, because it looks less readable to me. I suppose I might find that I got annoyed typing joinpath, but I doubt it. Also, because I have followed this PEP, I know that __div__ means joinwith, so if I read code that used path, I would understand it - it's too late for me to try reading code as a 'fresh' user and see if it confuses me or not. =Tony.Meyer -- http://mail.python.org/mailman/listinfo/python-list
Re: [path-PEP] Path inherits from basestring again
Hi All-- Tony Meyer wrote: So far, there have been various statements that look like +0 for __div__, but no-one with a +1. (And I've said this a couple of times now, which really is just trolling for a +1 from someone). It's not a question of saving characters, but readability which, as you've said, is a matter of opinion. I like / as a shortcut to joinwith(). I like it a lot. I like it so much I'll give you a +2. (Those who are offended by sweeping generalisations should ignore this next bit) I think it's also worth considering that Windows users are more clueless than users of posix systems. The readability of __div__ comes from familiarity with posix filesystems; for a Windows user, \ would be the natural character. So we're making things more readable for users that are already more likely figure things out, and less readable for users that have trouble figuring things out. This is not only bullshit, it's elitist bullshit. Windows users are more clueless than users of posix systems. Pfui. Prove it or withdraw it. 1. ISTM that standard library modules should be as readable as possible, even for those that don't use them. If I'm reading the source for module X and it uses a Path object, then it should be pretty straightforward to understand what is happening without also having to read the Path source/docs. This (readability without knowing the language/standard libraries) is a huge benefit of using Python. It's overrated. It must be macho to say I learned Python without reading books. Next you'll tell me you never ask for directions when you're lost. 2. If I did use the Path module, then I wouldn't use __div__, because it looks less readable to me. I suppose I might find that I got annoyed typing joinpath, but I doubt it. Also, because I have followed this PEP, I know that __div__ means joinwith, so if I read code that used path, I would understand it - it's too late for me to try reading code as a 'fresh' user and see if it confuses me or not. Then that's your right, but don't try to take / away from people who use it and like it. Metta, Ivan -- Ivan Van Laningham God N Locomotive Works http://www.andi-holmes.com/ http://www.foretec.com/python/workshops/1998-11/proceedings.html Army Signal Corps: Cu Chi, Class of '70 Author: Teach Yourself Python in 24 Hours -- http://mail.python.org/mailman/listinfo/python-list
RE: [path-PEP] Path inherits from basestring again
(Those who are offended by sweeping generalisations should ignore this next bit) [...generalisation bit snipped...] This is not only bullshit, it's elitist bullshit. Windows users are more clueless than users of posix systems. Pfui. Prove it or withdraw it. Sigh. I guess you didn't read or understand the first sentence? This (readability without knowing the language/standard libraries) is a huge benefit of using Python. It's overrated. It must be macho to say I learned Python without reading books. No it is not. Have you used Python as pseudocode when teaching people how to program? Many people have. That's just one example. Then that's your right, but don't try to take / away from people who use it and like it. People can subclass Path and add it if they really want it. They can use Jason's original module. My position is that the PEP without this use of __div__ is (a) better as a standard module, and (b) improves the chance of the PEP being accepted. =Tony.Meyer -- http://mail.python.org/mailman/listinfo/python-list
RE: [path-PEP] Path inherits from basestring again
def functions_which_modifies_some_file_in_place(path): output = open(path+'.tmp', 'w') . I dont want a seperator inserted between path and the new extension. Fair enough. Forget using '+' for join, then (which I was never that keen on - TIOWTDI), but I'm still -1 on using '/' for join. =Tony.Meyer -- http://mail.python.org/mailman/listinfo/python-list
RE: [path-PEP] Path inherits from basestring again
I, herewith, claim to have used it in the past. But I am indifferent as to if its needed, it just looks natural to me. So far there seem to have been a few +0s, but no +1s... What I use quite often is:: path(__file__).dirname() / somesiblingfileiknowisthere you do not have to think about trailing slashes or absolute vs. relative. and its much better than:: from os.path import * join(dirname(__file__), somesiblingfileiknowisthere) In what way is this much better? To me, this is much worse, because it is not at all clear what it means (a *huge* benefit of using Python is that you can read the code just like pseudocode). It is immediately clear from the second example that you are joining two things together. The first one, you could be joining, or you could be dividing. Compare: my_directory_string_object / somesiblingfileiknowisthere and my_directory_path_object / somesiblingfileiknowisthere These look the same, but one will raise a TypeError, and the other will result in a joined Path. How do I tell which is which when reading source, without explicitly saying that I'm using a Path object? __div__ is actually very convenient to build / a / very / very / long / path Would you really choose this: p = Path() / build / a / very / very / long / path Over this: p = Path(os.path.join(build, a, very, very, long, path)) ? A saving of six characters, and the second one is a lot clearer. If there was a os.path.joinPath (or whatever name) function that returned a Path object rather than a string, then you'd get: p = joinPath(build, a, very, very, long, path) Which is better (clearer, more concise) than either of the others, IMO. =Tony.Meyer -- http://mail.python.org/mailman/listinfo/python-list
RE: [path-PEP] Path inherits from basestring again
[using __div__ to mean join] I'm not too happy with it, too, but do we have alternatives? As paths are strings, we can hardly override the '+' operator, so there's not much operators left. Of course, one can use joinwith() if he doesn't like '/'. My argument is that the alternative is to not provide an operator for this, and to force people to use the appropriate join function (joinwith, I gather). Not everything needs to have an operator! (In Python, at least wink). Consider the 'discussion' regarding '@' and decorators. It's pretty clear that the Python community really isn't in favour of overloading characters with a lot of different meanings, and would much prefer being explicit (explicit is better than implicit, and all that). (Guido disagreed in this particular case, of course, but I believe that is an exception). I don't speak for python-dev or know for sure, but I suspect that the PEP would have a greater chance of acceptance (the goal, I presume) if this __div__ hackery wasn't in it. =Tony.Meyer -- http://mail.python.org/mailman/listinfo/python-list
RE: [path-PEP] Path inherits from basestring again
Well, I actually had some correspondence with Jason on this very subject a year or so ago: [...] Obviously, I don't know how much weight Jason's original ideas have on the prepped-for-syslib module, but it does support what other people have been saying: that the Path should behave like a string where a string is expected. Was that the whole email? It certainly adds weight to '+' having the normal string behaviour, but it didn't really say anything about why '/' should be a shortcut for join. Do you know if Jason had any reasoning for this other than laziness wink? =Tony.Meyer -- http://mail.python.org/mailman/listinfo/python-list
Re: [path-PEP] Path inherits from basestring again
On Wednesday 27 July 2005 05:37, Meyer, Tony wrote: I can see that this would make sense in some situations, but ISTM that it would make a great deal more sense (and be much more intuitive) to have concatenation include the separator character (i.e. be join). def functions_which_modifies_some_file_in_place(path): output = open(path+'.tmp', 'w') . I dont want a seperator inserted between path and the new extension. -- Toby Dickenson -- http://mail.python.org/mailman/listinfo/python-list
Re: [path-PEP] Path inherits from basestring again
Toby Dickenson wrote:
On Wednesday 27 July 2005 05:37, Meyer, Tony wrote:
I can see that this would make sense in some situations, but ISTM that it
would make a great deal more sense (and be much more intuitive) to have
concatenation include the separator character (i.e. be join).
def functions_which_modifies_some_file_in_place(path):
output = open(path+'.tmp', 'w')
.
I dont want a seperator inserted between path and the new extension.
My impression of '+', is it always join like objects...
str+str - str
list+list - list
tuple+tuple - tuple
So ...
path+path - path
In all current cases, (that I know of), of differing types, '+' raises
an error.
Question: Is a path object mutable?
Would the += operator create an new object or modify the original?
p = path('C://somedir//somefile')
p+='.zip' what would this do?
p[-1]+='.zip' Or this?
Cheer's Ron.
--
http://mail.python.org/mailman/listinfo/python-list
Re: [path-PEP] Path inherits from basestring again
Ron Adam wrote: In all current cases, (that I know of), of differing types, '+' raises an error. Not quite: hello + uworld u'hello world' 4.5 + 5 9.5 Question: Is a path object mutable? No. This should answer the rest of your questions. -- Michael Hoffman -- http://mail.python.org/mailman/listinfo/python-list
Re: [path-PEP] Path inherits from basestring again
Michael Hoffman wrote:
Ron Adam wrote:
In all current cases, (that I know of), of differing types, '+' raises
an error.
Not quite:
hello + uworld
u'hello world'
4.5 + 5
9.5
Question: Is a path object mutable?
No.
This should answer the rest of your questions.
Yes it does, thanks.
In the case of numeric types, it's an addition and not a join. I should
have specified in 'all cases, (I know of), where '+' is used to join
objects, but I thought that was clear from the context of the
discussion. I haven't needed to use unicode yet, so it didn't come to mind.
Although it raises other questions... ;-)
Could a string prefix be used with paths as well?
path = pC://somedir//somefile
Would that clash with the 'u' prefix? Or would we need a 'p' and a 'up'
prefix to differentiate the two?
(Just a thought. I'm +0 on this, but this seems to be a new string type,
and file operations are frequent and common.)
You could have both behaviors with the '+'.
path_a + path_b - join path_b to path_a using separator.
path + string - append string to path (no separator)
string + path - prepends string to path (no separator)
This would be similar, (but not exactly like), how u'text'+'text' and
'text'+u'text' work. They both return unicode strings given a standard
string. It would allow the following to work.
path = path('C:')+path('somedir')+path('somefile.txt')+'.zip'
- 'C://somedir//somefile.txt.zip'
So I guess the question here is which of these is preferable with '+'?
1. Strings act like paths when one is a path. They will be joined with
a separator.
2. Paths are joined with separators *and* a string is prepended or
postpended as is with no separator.
3. All path objects (and strings) act like strings. No separator is
used when joining path objects with '+'.
(Seems like #3 defeats the purpose of path a bit to me.)
I'm +1 on #2 after thinking about it.
Cheers,
Ron
--
http://mail.python.org/mailman/listinfo/python-list
Re: [path-PEP] Path inherits from basestring again
Ron Adam wrote: Michael Hoffman wrote: Ron Adam wrote: In all current cases, (that I know of), of differing types, '+' raises an error. Not quite: hello + uworld u'hello world' 4.5 + 5 9.5 In the case of numeric types, it's an addition and not a join. I should have specified in 'all cases, (I know of), where '+' is used to join objects, but I thought that was clear from the context of the discussion. I haven't needed to use unicode yet, so it didn't come to mind. I believe Michael intended to show that 4.5 + 5 actually represents using + with two different types, specifically a float and an int, thus giving at least two common cases where errors are not raised. (While the issue of addition vs. join is merely a (human) language issue... one could just as well say that those two numbers are being joined by the +.) -Peter -- http://mail.python.org/mailman/listinfo/python-list
Re: [path-PEP] Path inherits from basestring again
Peter Hansen wrote: Ron Adam wrote: Michael Hoffman wrote: Ron Adam wrote: In all current cases, (that I know of), of differing types, '+' raises an error. Not quite: hello + uworld u'hello world' 4.5 + 5 9.5 In the case of numeric types, it's an addition and not a join. I should have specified in 'all cases, (I know of), where '+' is used to join objects, but I thought that was clear from the context of the discussion. I haven't needed to use unicode yet, so it didn't come to mind. I believe Michael intended to show that 4.5 + 5 actually represents using + with two different types, specifically a float and an int, thus giving at least two common cases where errors are not raised. Yes, I got that distinction. Yet, concatenation isn't addition. Yes, they have some conceptual similarities, but they are two different operations that happen to use the same symbol for convenience. Three if you count lists and tuples join as being different from string concatinattion. (While the issue of addition vs. join is merely a (human) language issue... one could just as well say that those two numbers are being joined by the +.) -Peter It's also a Python language issue. ;-) Cheers, Ron -- http://mail.python.org/mailman/listinfo/python-list
Re: [path-PEP] Path inherits from basestring again
Peter Hansen wrote: Michael Hoffman wrote: Reinhold Birkenfeld wrote: Tony Meyer wrote: Do people really like using __div__ to mean join? I'm not too happy with it, too, but do we have alternatives? ... Of course, one can use joinwith() if he doesn't like '/'. I've used the path module pretty extensively and always use joinpath(). Personally, I'm -0 on __div__, but I suppose if anyone here claimed to have used in the past, rather than it just being some novelty that might be a good idea, that would be good enough for keeping it. I've tried it both ways, and ended up accepting / as a useful and clean approach, though as a general rule I find operator-overloading to be fairly hideous and to lead to Perlish code. This one I resisted for a while, then found it fairly pleasant, making it perhaps the exception to the rule... Perhaps it's just that in code that builds paths out of several components, it seemed quite straightforward to read when it used / instead of method calls. For example, from one program: scripts = userfolder / scriptfolder scriptpath = scripts / self.config['system']['commandfile'] instead of what used to be: scripts = userfolder.joinpath(scriptfolder) scriptpath = scripts.joinpath(self.config['system']['commandfile']) Even so I'm only +0 on it. -Peter I think the '+' is used as a join for both strings and lists, so it would probably be the better choice as far as consistency with the language is concerned. Cheers, Ron As for features we don't have yet, you could use an inerator. Something that gets stuff a little bit at a time. If you combine an iterator with a inerator, you would have a itinerator which would be quite useful for managing 'flight-paths'. ;-) -- http://mail.python.org/mailman/listinfo/python-list
Re: [path-PEP] Path inherits from basestring again
Ron Adam wrote: Tony Meyer wrote: Do people really like using __div__ to mean join? I think the '+' is used as a join for both strings and lists, so it would probably be the better choice as far as consistency with the language is concerned. The issue with that is that as long as we are subclassing strings, the + is already defined for a useful operation and the subclass probably shouldn't be changing the way that works. -Peter -- http://mail.python.org/mailman/listinfo/python-list
RE: [path-PEP] Path inherits from basestring again
[Peter Hansen]
|
| Ron Adam wrote:
| Tony Meyer wrote:
| Do people really like using __div__ to mean join?
|
| I think the '+' is used as a join for both strings and lists, so it
| would probably be the better choice as far as consistency with the
| language is concerned.
|
| The issue with that is that as long as we are subclassing
| strings, the +
| is already defined for a useful operation and the subclass probably
| shouldn't be changing the way that works.
Well, I actually had some correspondence with Jason on this
very subject a year or so ago:
email
[Me]
| Not sure if it's a bug or a feature, but __add__ does a + on the two
| strings/paths while the __div__ does a join. The principal difference from
| my point of view is that if I add two absolute paths: [...]
[Jason]
| Well... from my point of view, it's a feature... :)
| The purpose of + is (for example) to add extensions to the end of filenames:
| p = path('C:\\blorpl\\flarg.txt')
| z = p + '.zip'
| Without it, this would be pretty awkward.
| (path.__add__ is overloaded only to make this operation return a path
| object. Otherwise it would return a plain string.)
| The other purpose of + is so that a path behaves just like a string for all
| string operations. This means you can safely pass a path object to any
| function that expects a string.
/email
Obviously, I don't know how much weight Jason's original ideas have on
the prepped-for-syslib module, but it does support what other people
have been saying: that the Path should behave like a string where a
string is expected.
TJG
This e-mail has been scanned for all viruses by Star. The
service is powered by MessageLabs. For more information on a proactive
anti-virus service working around the clock, around the globe, visit:
http://www.star.net.uk
--
http://mail.python.org/mailman/listinfo/python-list
RE: [path-PEP] Path inherits from basestring again
[using __div__ to mean join] I think the '+' is used as a join for both strings and lists, so it would probably be the better choice as far as consistency with the language is concerned. +1. =Tony.Meyer -- http://mail.python.org/mailman/listinfo/python-list
RE: [path-PEP] Path inherits from basestring again
Do people really like using __div__ to mean join? I think the '+' is used as a join for both strings and lists, so it would probably be the better choice as far as consistency with the language is concerned. The issue with that is that as long as we are subclassing strings, the + is already defined for a useful operation and the subclass probably shouldn't be changing the way that works. But a Path isn't a string, it's string-like. I presume (but am too lazy to check) that at the moment using '+' on two Paths gives a Path that concatenates the __str__ versions of the Paths, like: Path(/foo/bar) + Path(/cat/dog) Path(/foo/bar/cat/dog) I can see that this would make sense in some situations, but ISTM that it would make a great deal more sense (and be much more intuitive) to have concatenation include the separator character (i.e. be join). =Tony.Meyer -- http://mail.python.org/mailman/listinfo/python-list
Re: [path-PEP] Path inherits from basestring again
Tony Meyer wrote: [...] Open issues: [...] What about path * 4? If you keep the current join meaning of __div__, then assigning any sort of multiplication meaning to __mul__ would not be a good idea, IMO. It's natural to expect that __div__ and __mul__ are opposites. I suppose this means that you could make __mul__ mean split (and f(*tuple) does do splitting of a sort), but I don't know what splitting by 4 would mean, necessarily. Yes. I think I'll not attach any meaning to it. If used, it will have the same meaning as string * 4. Do people really like using __div__ to mean join? On the python-dev discussion, Just van Rossum spoke out against it, but there weren't (IIRC) any other comments, either pro or con. I'm not too happy with it, too, but do we have alternatives? As paths are strings, we can hardly override the '+' operator, so there's not much operators left. Of course, one can use joinwith() if he doesn't like '/'. Reinhold -- http://mail.python.org/mailman/listinfo/python-list
Re: [path-PEP] Path inherits from basestring again
Andrew Dalke wrote: Reinhold Birkenfeld wrote: Okay. While a path has its clear use cases and those don't need above methods, it may be that some brain-dead functions needs them. brain-dead? Consider this code, which I think is not atypical. Okay, convinced. Reinhold -- http://mail.python.org/mailman/listinfo/python-list
Re: [path-PEP] Path inherits from basestring again
Reinhold Birkenfeld wrote: Hi, the arguments in the previous thread were convincing enough, so I made the Path class inherit from str/unicode again. Current change: * Add base() method for converting to str/unicode. * Allow compare against normal strings. Reinhold -- http://mail.python.org/mailman/listinfo/python-list
Re: [path-PEP] Path inherits from basestring again
Reinhold Birkenfeld wrote: * Add base() method for converting to str/unicode. +1 -- Michael Hoffman -- http://mail.python.org/mailman/listinfo/python-list
Re: [path-PEP] Path inherits from basestring again
Reinhold Birkenfeld wrote: Tony Meyer wrote: Do people really like using __div__ to mean join? On the python-dev discussion, Just van Rossum spoke out against it, but there weren't (IIRC) any other comments, either pro or con. I'm not too happy with it, too, but do we have alternatives? As paths are strings, we can hardly override the '+' operator, so there's not much operators left. Of course, one can use joinwith() if he doesn't like '/'. I've used the path module pretty extensively and always use joinpath(). Personally, I'm -0 on __div__, but I suppose if anyone here claimed to have used in the past, rather than it just being some novelty that might be a good idea, that would be good enough for keeping it. -- Michael Hoffman -- http://mail.python.org/mailman/listinfo/python-list
Re: [path-PEP] Path inherits from basestring again
on 25.07.2005 10:44 Michael Hoffman said the following: Reinhold Birkenfeld wrote: Tony Meyer wrote: Do people really like using __div__ to mean join? Of course, one can use joinwith() if he doesn't like '/'. Personally, I'm -0 on __div__, but I suppose if anyone here claimed to have used in the past, rather than it just being some novelty that might be a good idea, that would be good enough for keeping it. I, herewith, claim to have used it in the past. But I am indifferent as to if its needed, it just looks natural to me. What I use quite often is:: path(__file__).dirname() / somesiblingfileiknowisthere you do not have to think about trailing slashes or absolute vs. relative. and its much better than:: from os.path import * join(dirname(__file__), somesiblingfileiknowisthere) __div__ is actually very convenient to build / a / very / very / long / path (of course assuming the parts are strings not known initially...) -- http://mail.python.org/mailman/listinfo/python-list
Re: [path-PEP] Path inherits from basestring again
Stefan Rank wrote: on 25.07.2005 10:44 Michael Hoffman said the following: Reinhold Birkenfeld wrote: Tony Meyer wrote: Do people really like using __div__ to mean join? Of course, one can use joinwith() if he doesn't like '/'. Personally, I'm -0 on __div__, but I suppose if anyone here claimed to have used in the past, rather than it just being some novelty that might be a good idea, that would be good enough for keeping it. I, herewith, claim to have used it in the past. But I am indifferent as to if its needed, it just looks natural to me. What I use quite often is:: path(__file__).dirname() / somesiblingfileiknowisthere you do not have to think about trailing slashes or absolute vs. relative. and its much better than:: from os.path import * join(dirname(__file__), somesiblingfileiknowisthere) __div__ is actually very convenient to build / a / very / very / long / path (of course assuming the parts are strings not known initially...) Even knowing the parts that can be helpful if you want to be cross-platform. Reinhold -- http://mail.python.org/mailman/listinfo/python-list
Re: [path-PEP] Path inherits from basestring again
Michael Hoffman wrote: Reinhold Birkenfeld wrote: Tony Meyer wrote: Do people really like using __div__ to mean join? I'm not too happy with it, too, but do we have alternatives? ... Of course, one can use joinwith() if he doesn't like '/'. I've used the path module pretty extensively and always use joinpath(). Personally, I'm -0 on __div__, but I suppose if anyone here claimed to have used in the past, rather than it just being some novelty that might be a good idea, that would be good enough for keeping it. I've tried it both ways, and ended up accepting / as a useful and clean approach, though as a general rule I find operator-overloading to be fairly hideous and to lead to Perlish code. This one I resisted for a while, then found it fairly pleasant, making it perhaps the exception to the rule... Perhaps it's just that in code that builds paths out of several components, it seemed quite straightforward to read when it used / instead of method calls. For example, from one program: scripts = userfolder / scriptfolder scriptpath = scripts / self.config['system']['commandfile'] instead of what used to be: scripts = userfolder.joinpath(scriptfolder) scriptpath = scripts.joinpath(self.config['system']['commandfile']) Even so I'm only +0 on it. -Peter -- http://mail.python.org/mailman/listinfo/python-list
Re: [path-PEP] Path inherits from basestring again
Reinhold Birkenfeld wrote: Current change: * Add base() method for converting to str/unicode. Would basestring() be a better name? Partly because that seems to be exactly what it's doing, but more because there are (or used to be?) other things in Path that used the word base, such as basename. -1 on that specific name if it could be easily confused with basename types of things. -Peter -- http://mail.python.org/mailman/listinfo/python-list
Re: [path-PEP] Path inherits from basestring again
Reinhold Birkenfeld wrote: Peter Hansen wrote: Would basestring() be a better name? tobase? tostring? tobasestring? Of these choices, the latter would be preferable. Alternative is to set a class attribute Base of the Path class. Or export PathBase as a name from the module (but that's not quite useful, because I expect Path to be imported via from os.path import Path). I don't understand how that would work. An attribute on the *class*? What would it be, a callable? So mypath.Base(mypath) or something? Please elaborate... What about just .basestring, as a read-only attribute on the Path object? -Peter -- http://mail.python.org/mailman/listinfo/python-list
Re: [path-PEP] Path inherits from basestring again
Peter Hansen wrote: Reinhold Birkenfeld wrote: Peter Hansen wrote: Would basestring() be a better name? tobase? tostring? tobasestring? Of these choices, the latter would be preferable. Alternative is to set a class attribute Base of the Path class. Or export PathBase as a name from the module (but that's not quite useful, because I expect Path to be imported via from os.path import Path). I don't understand how that would work. An attribute on the *class*? What would it be, a callable? So mypath.Base(mypath) or something? Please elaborate... [_base is str or unicode] class Path: Base = _base [...] So you could do Path.Base(mypath) or mypath.Base(mypath). What about just .basestring, as a read-only attribute on the Path object? Reasonable, though the term as such is preoccupied too. Reinhold -- http://mail.python.org/mailman/listinfo/python-list
Re: [path-PEP] Path inherits from basestring again
Reinhold Right, that was a concern of mine, too. Reinhold tobase? Reinhold tostring? Reinhold tobasestring? If we're on a filesystem that understands unicode, would somepath.tostring() return a unicode object or a string object encoded with some to-be-determined encoding? Why not just add __str__ and __unicode__ methods to the class and let the user use str(somepath) or unicode(somepath) as needed? Or am I missing something fundamental about what the base() method is supposed to do? Skip -- http://mail.python.org/mailman/listinfo/python-list
Re: [path-PEP] Path inherits from basestring again
[EMAIL PROTECTED] wrote: Reinhold Right, that was a concern of mine, too. Reinhold tobase? Reinhold tostring? Reinhold tobasestring? If we're on a filesystem that understands unicode, would somepath.tostring() return a unicode object or a string object encoded with some to-be-determined encoding? Whatever the base of the Path object is. It selects its base class based on os.path.supports_unicode_filenames. Why not just add __str__ and __unicode__ methods to the class and let the user use str(somepath) or unicode(somepath) as needed? Or am I missing something fundamental about what the base() method is supposed to do? It should provide an alternative way of spelling Path.__bases__[0](path). Reinhold -- http://mail.python.org/mailman/listinfo/python-list
Re: [path-PEP] Path inherits from basestring again
Reinhold Birkenfeld wrote: Current change: * Add base() method for converting to str/unicode. Now that [:] slicing works, and returns a string, another way to convert from path.Path to str/unicode is path[:] Andrew [EMAIL PROTECTED] -- http://mail.python.org/mailman/listinfo/python-list
Re: [path-PEP] Path inherits from basestring again
On Mon, 25 Jul 2005 11:19:25 -0400, Peter Hansen [EMAIL PROTECTED] wrote: Michael Hoffman wrote: Reinhold Birkenfeld wrote: Tony Meyer wrote: Do people really like using __div__ to mean join? I'm not too happy with it, too, but do we have alternatives? ... Of course, one can use joinwith() if he doesn't like '/'. I've used the path module pretty extensively and always use joinpath(). Personally, I'm -0 on __div__, but I suppose if anyone here claimed to have used in the past, rather than it just being some novelty that might be a good idea, that would be good enough for keeping it. I've tried it both ways, and ended up accepting / as a useful and clean approach, though as a general rule I find operator-overloading to be fairly hideous and to lead to Perlish code. This one I resisted for a while, then found it fairly pleasant, making it perhaps the exception to the rule... Perhaps it's just that in code that builds paths out of several components, it seemed quite straightforward to read when it used / instead of method calls. For example, from one program: scripts = userfolder / scriptfolder scriptpath = scripts / self.config['system']['commandfile'] instead of what used to be: scripts = userfolder.joinpath(scriptfolder) scriptpath = scripts.joinpath(self.config['system']['commandfile']) Even so I'm only +0 on it. (;-) How about a __use_adjacent_operand__ op with simple expression white-space-separated adjacency implying it? Then you could leave out the '/' and write scripts = userfolder scriptfolder scriptpath = scripts self.config['system']['commandfile'] Hm, if you made that __hadjacent__ for horizontal whitespace, and __vadjacent__ if the white space included '\n', then you could form even two-dimensional arrays without all that of punctuation (except that you'd need an explicit ending ';' for the above or () most likely for 2D) (funnyarray() 1 2 3 4 5 6 ) BTW, more OT, wouldn't '|' be more platform-neutral as the joining operator? ;-) Regards, Bengt Richter -- http://mail.python.org/mailman/listinfo/python-list
Re: [path-PEP] Path inherits from basestring again
On Mon, 25 Jul 2005 17:33:51 +0200, Reinhold Birkenfeld [EMAIL PROTECTED] wrote: Peter Hansen wrote: Reinhold Birkenfeld wrote: Current change: * Add base() method for converting to str/unicode. Would basestring() be a better name? Partly because that seems to be exactly what it's doing, but more because there are (or used to be?) other things in Path that used the word base, such as basename. -1 on that specific name if it could be easily confused with basename types of things. Right, that was a concern of mine, too. tobase? -1 tostring? +1 tobasestring? -0 Alternative is to set a class attribute Base of the Path class. Or export PathBase as a name from the module (but that's not quite useful, because I expect Path to be imported via from os.path import Path). Reinhold Regards, Bengt Richter -- http://mail.python.org/mailman/listinfo/python-list
Re: [path-PEP] Path inherits from basestring again
Bengt Richter wrote: BTW, more OT, wouldn't '|' be more platform-neutral as the joining operator? I, on the other hand, would certainly prefer U+01C1. Reinhold -- http://mail.python.org/mailman/listinfo/python-list
Re: [path-PEP] Path inherits from basestring again
Peter Hansen wrote: Point taken. What about ditching the file part, since it is redundant and obvious that a file is in fact what is being accessed. Thus: .read_bytes(), .read_text(), .write_lines() etc. +1. Although I've always been somewhat -0 on these methods to start with. -- Michael Hoffman -- http://mail.python.org/mailman/listinfo/python-list
Re: [path-PEP] Path inherits from basestring again
Peter Hansen wrote:
Reinhold Birkenfeld wrote:
[on comparing Paths and stings]
Do you have a use case for the comparison? Paths should be compared only
with other paths.
I can think of lots, though I don't know that I've used any in my
existing (somewhat limited) code that uses Path, but they all involve
cases where I would expect, if comparisons were disallowed, to just wrap
the string in a Path first, even though to me that seems like it should
be an unnecessary step:
if mypath.splitpath()[0] == 'c:/temp':
if 'tests' in mypath.dirs():
and lots of other uses which start by treating a Path as a string
first, such as by doing .endswith('_unit.py')
endswith is okay, since it is an inherited method from str.
Any of these could be resolved by ensuring both are Paths, but then I'm
not sure there's much justification left for using a baseclass of
basestring in the first place:
if mypath.splitpath()[0] == Path('c:/temp'):
But you must admit that that't the cleaner solution.
if Path('tests') in mypath.dirs():
Question: would this latter one actually work? Would this check items
in the list using comparison or identity? Identity would simply be
wrong here.
Yes, it works. I didn't do anything to make it work, but Path seems to inherit
the immutableness from str.
[on removing properties in favour of methods for volatile data]
My line of thought is that a path may, but does not need to refer to an
existing, metadata-readable file. For this, I think a property is not
proper.
Fair enough, though in either case an attempt to access that information
leads to the same exception. I can't make a strong argument in favour
of properties (nor against them, really).
Okay.
What about iteration and indexing? Should it support
for element in path or for char in path or nothing?
As John Roth suggests, the former seems a much more useful thing to do.
The latter is probably as rarely needed as it is with regular strings
(which I believe is roughly never in Python).
[on .read_file_bytes() etc]
I think it is not exactly bad that these names are somehow outstanding,
as that demonstrates that something complex and special happens.
Point taken. What about ditching the file part, since it is redundant
and obvious that a file is in fact what is being accessed. Thus:
.read_bytes(), .read_text(), .write_lines() etc.
Hm. Is it so clear that a it's about a file? A path can point to anything,
so I think it's better to clearly state that this is only for a file at the
path, if it exists.
Reinhold
--
http://mail.python.org/mailman/listinfo/python-list
Re: [path-PEP] Path inherits from basestring again
Reinhold Birkenfeld wrote: Hi, the arguments in the previous thread were convincing enough, so I made the Path class inherit from str/unicode again. Further changes by now: * subdirs() is now dirs(). * fixed compare behaviour for unicode base (unicode has no rich compare) * __iter__() iterates over the parts(). * the following methods raise NotImplemented: capitalize, expandtabs, join, splitlines, title, zfill Open issues: What about the is* string methods? What about __contains__ and __getitem__? What about path * 4? Reinhold -- http://mail.python.org/mailman/listinfo/python-list
Re: [path-PEP] Path inherits from basestring again
Reinhold Birkenfeld wrote: * __iter__() iterates over the parts(). * the following methods raise NotImplemented: capitalize, expandtabs, join, splitlines, title, zfill Why? They *are* implemented. I do not understand this desire to wantonly break basestring compatiblity for the sake of breaking compatibility. Once you break compatibility with basestring you can no longer use a path anywhere that you could have used a str or unicode before. With compatibility broken, the only possible supported way of passing paths to third-party functions will be to cast the path with path.__bases__[0](mypath) before passing it anywhere else. You can't even use str() because you don't know what the base class of the path is. What a pain. From the original path.py documentation: os.path.join doesn't map to path.join(), because there's a string method with that name. Instead it's path.joinpath(). This is a nuisance, but changing the semantics of base class methods is worse. (I know, I tried it.) The same goes for split(). It ain't broke. Please stop breaking it. -- Michael Hoffman -- http://mail.python.org/mailman/listinfo/python-list
Re: [path-PEP] Path inherits from basestring again
Hi All-- Reinhold Birkenfeld wrote: Reinhold Birkenfeld wrote: Hi, the arguments in the previous thread were convincing enough, so I made the Path class inherit from str/unicode again. Thanks. * the following methods raise NotImplemented: capitalize, expandtabs, join, splitlines, title, zfill If path inherits from str or unicode, why not leave these? I can certainly see uses for capitalize(), title() and zfill() when trying to coerce Windows to let me use the case that I put there in the first place;-) What if I wanted to take a (legitimate) directory name 'parking\tlot' and change it to 'parkinglot'? Open issues: What about the is* string methods? What about them? What makes you think these wouldn't be useful? Imagine directory names made up of all numbers; wouldn't it be useful to know which directories in a tree of, say, digital camera images, comprise all numbers, all hex numbers, or alpha only? What about __contains__ and __getitem__? I find it hard to imagine what would be returned when asking a path for say, path[c:], other than the index. n=path[c:] = 0 ? What about path * 4? This one makes my brain hurt, I admit;-) Metta, Ivan -- Ivan Van Laningham God N Locomotive Works http://www.andi-holmes.com/ http://www.foretec.com/python/workshops/1998-11/proceedings.html Army Signal Corps: Cu Chi, Class of '70 Author: Teach Yourself Python in 24 Hours -- http://mail.python.org/mailman/listinfo/python-list
Re: [path-PEP] Path inherits from basestring again
Michael Hoffman wrote: Reinhold Birkenfeld wrote: * __iter__() iterates over the parts(). * the following methods raise NotImplemented: capitalize, expandtabs, join, splitlines, title, zfill Why? They *are* implemented. I do not understand this desire to wantonly break basestring compatiblity for the sake of breaking compatibility. Once you break compatibility with basestring you can no longer use a path anywhere that you could have used a str or unicode before. With compatibility broken, the only possible supported way of passing paths to third-party functions will be to cast the path with path.__bases__[0](mypath) before passing it anywhere else. You can't even use str() because you don't know what the base class of the path is. What a pain. From the original path.py documentation: os.path.join doesn't map to path.join(), because there's a string method with that name. Instead it's path.joinpath(). This is a nuisance, but changing the semantics of base class methods is worse. (I know, I tried it.) The same goes for split(). It ain't broke. Please stop breaking it. Okay. While a path has its clear use cases and those don't need above methods, it may be that some brain-dead functions needs them. Reinhold -- http://mail.python.org/mailman/listinfo/python-list
Re: [path-PEP] Path inherits from basestring again
Reinhold Birkenfeld wrote:
Peter Hansen wrote:
if mypath.splitpath()[0] == 'c:/temp':
vs.
if mypath.splitpath()[0] == Path('c:/temp'):
But you must admit that that't the cleaner solution.
Cleaner? Not at all. I'd say it's the more expressive solution,
perhaps, but I definitely wouldn't choose the word cleaner for
something which, to me, adds fairly unnecessary text.
But it's clearly a subjective matter, and as the one of us not involved
in doing the real work here, I'll bow to your judgement on the matter. ;-)
-Peter
--
http://mail.python.org/mailman/listinfo/python-list
Re: [path-PEP] Path inherits from basestring again
Steven D'Aprano [EMAIL PROTECTED] writes: On Sat, 23 Jul 2005 17:51:31 -0600, John Roth wrote: I also like to know the number of elements, which seems to make sense as len(path). Again, the number of characters in the path seems to be utterly useless information - at least, I can't imagine a use for it. There are (were?) operating systems that could only deal with a maximum length for pathnames. If I recall correctly, and I probably don't, Classic Mac (pre-OS X) was limited to file names of 31 or fewer characters and no more than 250-odd for the entire pathname. At the very least, some file manager routines would work and some would not. Are. But I think they're a lot longer now. bhuda% grep PATH_MAX /usr/include/sys/syslimits.h #define PATH_MAX 1024 /* max bytes in pathname */ mike -- Mike Meyer [EMAIL PROTECTED] http://www.mired.org/home/mwm/ Independent WWW/Perforce/FreeBSD/Unix consultant, email for more information. -- http://mail.python.org/mailman/listinfo/python-list
Re: [path-PEP] Path inherits from basestring again
Peter Hansen wrote:
Reinhold Birkenfeld wrote:
Peter Hansen wrote:
if mypath.splitpath()[0] == 'c:/temp':
vs.
if mypath.splitpath()[0] == Path('c:/temp'):
But you must admit that that't the cleaner solution.
Cleaner? Not at all. I'd say it's the more expressive solution,
perhaps, but I definitely wouldn't choose the word cleaner for
something which, to me, adds fairly unnecessary text.
But it's clearly a subjective matter, and as the one of us not involved
in doing the real work here, I'll bow to your judgement on the matter. ;-)
I'm in no way the last instance on this.
For example, everyone with CVS access is free to change the files ;)
Honestly, I'm in constant fear that allowing too much and loading too much
features won't increase the acceptance of python-dev wink
Reinhold
--
http://mail.python.org/mailman/listinfo/python-list
Re: [path-PEP] Path inherits from basestring again
Reinhold Birkenfeld wrote: I'm in no way the last instance on this. For example, everyone with CVS access is free to change the files ;) I don't have CVS write access :(, so I'll have to keep kibitzing for now. Honestly, I'm in constant fear that allowing too much and loading too much features won't increase the acceptance of python-dev wink What do you mean by this? To me code like this: if _base is str: def __eq__(self, other): return isinstance(other, Path) and _base.__eq__(self, other) [...] else: # Unicode has no rich compare methods def __cmp__(self, other): if isinstance(other, Path): return _base.__cmp__(self, other) return NotImplemented is the feature that you do not need: the feature of not returning True. You don't need this feature, and I consider it to be harmful. It breaks duck-typing unnecessarily, and means that people who want to use some other path library, or just str/unicode as they do today cannot compare those paths against stdlib Paths. We should retain the design principle of the original path.py that Path objects should be drop-in replacements for the str or unicode objects they replace, as much as possible. We cannot predict all the things people are doing with strings today, and attempting to do so can only lead to bugs. In the current implementation, the only cases where a path object cannot be used as a drop-in replacement for a string are (a) some extension modules, and (b) code that tests the object class using type() instead of using isinstance(). I think these are unavoidable but other incompatibilities, like changing the semantics of comparisons or join() are avoidable. I've started a Wiki page for design principles and discussion here: http://wiki.python.org/moin/PathClass -- Michael Hoffman -- http://mail.python.org/mailman/listinfo/python-list
Re: [path-PEP] Path inherits from basestring again
Reinhold Birkenfeld wrote:
Okay. While a path has its clear use cases and those don't need above methods,
it may be that some brain-dead functions needs them.
brain-dead?
Consider this code, which I think is not atypical.
import sys
def _read_file(filename):
if filename == -:
# Can use '-' to mean stdin
return sys.stdin
else:
return open(filename, rU)
def file_sum(filename):
total = 0
for line in _read_file(filename):
total += int(line)
return total
(Actually, I would probably write it
def _read_file(file):
if isinstance(file, basestring):
if filename == -:
# Can use '-' to mean stdin
return sys.stdin
else:
return open(filename, rU)
return file
)
Because the current sandbox Path doesn't support
the is-equal test with strings, the above function
won't work with a filename = path.Path(-). It
will instead raise an exception saying
IOError: [Errno 2] No such file or directory: '-'
(Yes, the code as-is can't handle a file named '-'.
The usual workaround (and there are many programs
which support '-' as an alias for stdin) is to use ./-
% cat './-'
This is a file
% cat ./-
This is a file
% cat -
I'm typing directly into stdin.
^D
I'm typing directly into stdin.
%
)
If I start using the path.Path then in order to use
this function my upstream code must be careful on
input to distinguish between filenames which are
really filenames and which are special-cased pseudo
filenames.
Often the code using the API doesn't even know which
names are special. Even if it is documented,
the library developer may decide in the future to
extend the list of pseudo filenames to include, say,
environment variable style expansion, as
$HOME/.config
Perhaps the library developer should have come up
with a new naming system to include both types of
file naming schemes, but that's rather overkill.
As a programmer calling the API should I convert
all my path.Path objects to strings before using it?
Or to Unicode? How do I know which filenames will
be treated specially through time?
Is there a method to turn a path.Path into the actual
string? str() and unicode() don't work because I
want the result to be unicode if the OSPython build
support it, otherwise string.
Is that library example I mentioned brain-dead?
I don't think so. Instead I think you are pushing
too much for purity and making changes that will
cause problems - and hard to fix problems - with
existing libraries.
Here's an example of code from an existing library
which will break in several ways if it's passed a
path object instead of a string. It comes from
spambayes/mboxutils.py
#
This is mostly a wrapper around the various useful classes in the
standard mailbox module, to do some intelligent guessing of the
mailbox type given a mailbox argument.
+foo -- MH mailbox +foo
+foo,bar -- MH mailboxes +foo and +bar concatenated
+ALL -- a shortcut for *all* MH mailboxes
/foo/bar -- (existing file) a Unix-style mailbox
/foo/bar/ -- (existing directory) a directory full of .txt and .lorien
files
/foo/bar/ -- (existing directory with a cur/ subdirectory)
Maildir mailbox
/foo/Mail/bar/ -- (existing directory with /Mail/ in its path)
alternative way of spelling an MH mailbox
def getmbox(name):
Return an mbox iterator given a file/directory/folder name.
if name == -:
return [get_message(sys.stdin)]
if name.startswith(+):
# MH folder name: +folder, +f1,f2,f2, or +ALL
name = name[1:]
import mhlib
mh = mhlib.MH()
if name == ALL:
names = mh.listfolders()
elif ',' in name:
names = name.split(',')
else:
names = [name]
mboxes = []
mhpath = mh.getpath()
for name in names:
filename = os.path.join(mhpath, name)
mbox = mailbox.MHMailbox(filename, get_message)
mboxes.append(mbox)
if len(mboxes) == 1:
return iter(mboxes[0])
else:
return _cat(mboxes)
if os.path.isdir(name):
# XXX Bogus: use a Maildir if /cur is a subdirectory, else a MHMailbox
# if the pathname contains /Mail/, else a DirOfTxtFileMailbox.
if os.path.exists(os.path.join(name, 'cur')):
mbox = mailbox.Maildir(name, get_message)
elif name.find(/Mail/) = 0:
mbox = mailbox.MHMailbox(name, get_message)
else:
mbox = DirOfTxtFileMailbox(name, get_message)
else:
fp = open(name, rb)
mbox = mailbox.PortableUnixMailbox(fp, get_message)
return iter(mbox)
It breaks with the current sandbox path because:
- a path can't be compared to -
- range isn't supported, as name = name[1:]
note that this example uses __contains__ (, in name)
Is this function brain-dead? Is it reasonable that people might
want to pass a path.Path() directly to it? If not, what's
the way
RE: [path-PEP] Path inherits from basestring again
[...] Open issues: [...] What about path * 4? If you keep the current join meaning of __div__, then assigning any sort of multiplication meaning to __mul__ would not be a good idea, IMO. It's natural to expect that __div__ and __mul__ are opposites. I suppose this means that you could make __mul__ mean split (and f(*tuple) does do splitting of a sort), but I don't know what splitting by 4 would mean, necessarily. Do people really like using __div__ to mean join? On the python-dev discussion, Just van Rossum spoke out against it, but there weren't (IIRC) any other comments, either pro or con. I'm -1, myself. Apart from TIOOTDI, it doesn't seem a natural use for the '/' character. I suppose that it looks nice, when one is used to posix paths, but not everyone is, and I'm sure that more people would expect some sort of division (the exact opposite!) than join. =Tony.Meyer -- http://mail.python.org/mailman/listinfo/python-list
[path-PEP] Path inherits from basestring again
Hi,
the arguments in the previous thread were convincing enough, so I made the
Path class inherit from str/unicode again.
It still can be found in CVS:
/python/nondist/sandbox/path/{path.py,test_path.py}
One thing is still different, though: a Path instance won't compare to a regular
string.
Other minor differences, as requested on python-dev, are:
* size property - getsize() method.
* atime/mtime/ctime properties - atime()/mtime()/ctime() methods
* dirname() method - directory property
* no parent property
* basename() method - basename property
* no name property
* listdir() method - children() method
* there is still a listdir() method, but with the semantics of os.listdir
* dirs() method - subdirs() method
* joinpath() method - added alias joinwith()
* splitall() method - parts() method
* Default constructor: Path() == Path(os.curdir)
* staticmethod Path.getcwd() - Path.cwd()
* bytes() / lines() / text() - read_file_{bytes,lines,text} methods
* write_{bytes,lines,text} - write_file_{bytes,lines,text} methods
These may be removed though.
Reinhold
--
http://mail.python.org/mailman/listinfo/python-list
Re: [path-PEP] Path inherits from basestring again
Reinhold Birkenfeld wrote:
One thing is still different, though: a Path instance won't compare to a
regular
string.
Could you please expand on what this means? Are you referring to doing
and = type operations on Paths and strings, or == and != or all those
or something else entirely?
Other minor differences, as requested on python-dev, are:
* size property - getsize() method.
* atime/mtime/ctime properties - atime()/mtime()/ctime() methods
What does this mean? The .size property and a getsize() method both
already exist (in my copy of path.py anyway) and do the same thing.
Same with the other ones mentioned above. Is someone working from an
out-of-date copy of path.py?
* dirs() method - subdirs() method
Given that .files() exists, and returns a list of the files contained in
a path which represents a folder, why would one want to use subdirs()
instead of just dirs() to do the same operation for contained folders?
If subdirs() is preferred, then I suggest subfiles() as well. Otherwise
the change seems arbitrary and ill-conceived.
* joinpath() method - added alias joinwith()
* splitall() method - parts() method
This reminds me of the *one* advantage I can think of for not
subclassing basestring, though it still doesn't make the difference in
my mind: strings already have split(), so Jason had to go with
splitpath() for the basic split operation to avoid a conflict. A
minor wart I guess.
* Default constructor: Path() == Path(os.curdir)
To construct an empty path then one can still do Path('') ?
* staticmethod Path.getcwd() - Path.cwd()
* bytes() / lines() / text() - read_file_{bytes,lines,text} methods
* write_{bytes,lines,text} - write_file_{bytes,lines,text} methods
Under Linux isn't it possible to open and read from directories much as
with files? If that's true, the above would seem to conflict with that
in some way. As with the the .subdirs() suggestion above, these changes
seem to me somewhat arbitrary. .bytes() and friends have felt quite
friendly in actual use, and I suspect .read_file_bytes() will feel quite
unwieldy. Not a show-stopper however.
-Peter
--
http://mail.python.org/mailman/listinfo/python-list
Re: [path-PEP] Path inherits from basestring again
Peter Hansen wrote:
Under Linux isn't it possible to open and read from directories much as
with files?
Not really, no.
Python 2.3.4 (#2, Jan 5 2005, 08:24:51)
[GCC 3.3.5 (Debian 1:3.3.5-5)] on linux2
Type help, copyright, credits or license for more information.
d = open('/usr/bin')
Traceback (most recent call last):
File stdin, line 1, in ?
IOError: [Errno 21] Is a directory
--
Robert Kern
[EMAIL PROTECTED]
In the fields of hell where the grass grows high
Are the graves of dreams allowed to die.
-- Richard Harter
--
http://mail.python.org/mailman/listinfo/python-list
Re: [path-PEP] Path inherits from basestring again
Peter Hansen wrote:
Reinhold Birkenfeld wrote:
One thing is still different, though: a Path instance won't compare to a
regular
string.
Could you please expand on what this means? Are you referring to doing
and = type operations on Paths and strings, or == and != or all those
or something else entirely?
All of these. Do you need them?
Other minor differences, as requested on python-dev, are:
* size property - getsize() method.
* atime/mtime/ctime properties - atime()/mtime()/ctime() methods
What does this mean? The .size property and a getsize() method both
already exist (in my copy of path.py anyway) and do the same thing.
Same with the other ones mentioned above. Is someone working from an
out-of-date copy of path.py?
No. But the size of a file is somewhat volatile, and does not feel like
a property of the path to it. Remember: the path is not the file. Same
goes with the xtime() methods.
Different is the basename/directory/etc.: as long as the path stays the same,
these properties will stay the same.
* dirs() method - subdirs() method
Given that .files() exists, and returns a list of the files contained in
a path which represents a folder, why would one want to use subdirs()
instead of just dirs() to do the same operation for contained folders?
If subdirs() is preferred, then I suggest subfiles() as well. Otherwise
the change seems arbitrary and ill-conceived.
Well, I think that's right. Will change back to dirs().
* joinpath() method - added alias joinwith()
* splitall() method - parts() method
This reminds me of the *one* advantage I can think of for not
subclassing basestring, though it still doesn't make the difference in
my mind: strings already have split(), so Jason had to go with
splitpath() for the basic split operation to avoid a conflict. A
minor wart I guess.
At the moment, I think about overriding certain string methods that make
absolutely no sense on a path and raising an exception from them.
* Default constructor: Path() == Path(os.curdir)
To construct an empty path then one can still do Path('') ?
Yes.
* staticmethod Path.getcwd() - Path.cwd()
* bytes() / lines() / text() - read_file_{bytes,lines,text} methods
* write_{bytes,lines,text} - write_file_{bytes,lines,text} methods
Under Linux isn't it possible to open and read from directories much as
with files? If that's true, the above would seem to conflict with that
in some way. As with the the .subdirs() suggestion above, these changes
seem to me somewhat arbitrary. .bytes() and friends have felt quite
friendly in actual use, and I suspect .read_file_bytes() will feel quite
unwieldy. Not a show-stopper however.
It has even been suggested to throw them out, as they don't have so much to
do with a path per se. When the interface is too burdened, we'll have less
chance to be accepted. Renaming these makes clear that they are not operations
on the path, but on a file the path points to.
Phillip J. Eby suggested these to be set_file_xxx and get_file_xxx to
demonstrate
that they do not read or write a stream; how about that?
Reinhold
--
http://mail.python.org/mailman/listinfo/python-list
Re: [path-PEP] Path inherits from basestring again
Reinhold Birkenfeld wrote:
Peter Hansen wrote (on Paths not allowing comparison with strings):
Could you please expand on what this means? Are you referring to doing
and = type operations on Paths and strings, or == and != or all those
or something else entirely?
All of these. Do you need them?
I believe so. If they are going to be basestring subclasses, why should
they be restricted in any particular way? I suppose that if you wanted
to compare a Path to a string, you could just wrap the string in a Path
first, but if the Path is already a basestring subclass, why make
someone jump through that particular hoop?
Other minor differences, as requested on python-dev, are:
* size property - getsize() method.
* atime/mtime/ctime properties - atime()/mtime()/ctime() methods
What does this mean? The .size property and a getsize() method both
already exist (in my copy of path.py anyway) and do the same thing.
Same with the other ones mentioned above. Is someone working from an
out-of-date copy of path.py?
No. But the size of a file is somewhat volatile, and does not feel like
a property of the path to it. Remember: the path is not the file. Same
goes with the xtime() methods.
Oh, so your original text was meant to imply that those properties *were
being removed*. That wasn't at all clear to me.
I understand the reasoning, but I'm unsure I agree with it. I fully
accept that the path is not the file, and yet I have a feeling this is a
pedanticism: most of the time when one is dealing with the _file_ one is
concerned with the content, and not much else. When one is dealing with
the _path_ one often wants to check the size, the modification time, and
so forth. For example, once one has the file open, one very rarely is
interested in when it was last modified.
In other words, I feel once again that Jason's original intuition here
was excellent, and that he chose practicality over purity in appropriate
ways, in a very Pythonic fashion. I confess to feeling that the
suggested changes are being proposed by those who have never actually
tried to put path.py to use in practical code, though I'm sure that's
not the case for everyone making those suggestions.
Still, once again this doesn't seem a critical issue to me and I'm happy
with either approach, if it means Path gets accepted in the stdlib.
At the moment, I think about overriding certain string methods that make
absolutely no sense on a path and raising an exception from them.
That would seem reasonable. It seems best to be very tolerant about
what makes no sense, though istitle() would surely be one of those to
go first. Also capitalize() (in spite of what Windows Explorer seems to
do sometimes), center(), expandtabs(), ljust(), rjust(), splitlines(),
title(), and zfill(). Hmm... maybe not zfill() actually. I could
imagine an actual (if rare) use for that.
.bytes() and friends have felt quite
friendly in actual use, and I suspect .read_file_bytes() will feel quite
unwieldy. Not a show-stopper however.
It has even been suggested to throw them out, as they don't have so much to
do with a path per se. When the interface is too burdened, we'll have less
chance to be accepted. Renaming these makes clear that they are not operations
on the path, but on a file the path points to.
Here again I would claim the practicality over purity argument. When
one has a Path, it is very frequently because one intends to open a file
object using it and do reads and writes (obviously). Also very often,
the type of reading and writing one wants to do is an all at once type
of thing, as those methods support. They're merely a convenience, to
save one doing the Path(xxx).open('rb').read thing when one can merely
do Path(xxx).bytes(), in much the same way that the whole justification
for Path() is that it bundles useful and commonly used operations
together into one place.
Phillip J. Eby suggested these to be set_file_xxx and get_file_xxx to
demonstrate
that they do not read or write a stream; how about that?
If they are there, they do exactly what they do, don't they? And they
do file.read() and file.write() operations, with slight nuances in the
mode passed to open() or the way the data is manipulated. Why would one
want to hide that, making it even harder to tie these operations
together with what is really going on under the covers? I think the
existing names, or at least ones with _read_ and _write_ in them
somewhere are better than set/get alternatives. It's just rare in
Python to encounter names quite as cumbersome as _write_file_bytes().
It might be good for those involved to discuss and agree on the
philosophy/principles behind using Path in the first place. If it's one
of pragmatism, then the arguments in favour of strictly differentiating
between path- and file- related operations should probably not be given
as much weight as those in favour of simple and convenient access
Re: [path-PEP] Path inherits from basestring again
Peter Hansen [EMAIL PROTECTED] writes:
* staticmethod Path.getcwd() - Path.cwd()
* bytes() / lines() / text() - read_file_{bytes,lines,text} methods
* write_{bytes,lines,text} - write_file_{bytes,lines,text} methods
Under Linux isn't it possible to open and read from directories much
as with files?
The OS doesn't matter - python won't let you open a directory as a
file, even if the underlying OS will. The comment in
Objects/fileobject.c is:
/* On Unix, fopen will succeed for directories.
In Python, there should be no file objects referring to
directories, so we need a check. */
I think - but I'm not positive, and don't have a Linux box handy to
check on - that this comment is false if your Unix is really Linux.
mike
--
Mike Meyer [EMAIL PROTECTED] http://www.mired.org/home/mwm/
Independent WWW/Perforce/FreeBSD/Unix consultant, email for more information.
--
http://mail.python.org/mailman/listinfo/python-list
Re: [path-PEP] Path inherits from basestring again
Peter Hansen wrote:
Reinhold Birkenfeld wrote:
Peter Hansen wrote (on Paths not allowing comparison with strings):
Could you please expand on what this means? Are you referring to doing
and = type operations on Paths and strings, or == and != or all those
or something else entirely?
All of these. Do you need them?
I believe so. If they are going to be basestring subclasses, why should
they be restricted in any particular way? I suppose that if you wanted
to compare a Path to a string, you could just wrap the string in a Path
first, but if the Path is already a basestring subclass, why make
someone jump through that particular hoop?
Do you have a use case for the comparison? Paths should be compared only
with other paths.
Other minor differences, as requested on python-dev, are:
* size property - getsize() method.
* atime/mtime/ctime properties - atime()/mtime()/ctime() methods
What does this mean? The .size property and a getsize() method both
already exist (in my copy of path.py anyway) and do the same thing.
Same with the other ones mentioned above. Is someone working from an
out-of-date copy of path.py?
No. But the size of a file is somewhat volatile, and does not feel like
a property of the path to it. Remember: the path is not the file. Same
goes with the xtime() methods.
Oh, so your original text was meant to imply that those properties *were
being removed*. That wasn't at all clear to me.
I understand the reasoning, but I'm unsure I agree with it. I fully
accept that the path is not the file, and yet I have a feeling this is a
pedanticism: most of the time when one is dealing with the _file_ one is
concerned with the content, and not much else. When one is dealing with
the _path_ one often wants to check the size, the modification time, and
so forth. For example, once one has the file open, one very rarely is
interested in when it was last modified.
My line of thought is that a path may, but does not need to refer to an
existing, metadata-readable file. For this, I think a property is not
proper.
In other words, I feel once again that Jason's original intuition here
was excellent, and that he chose practicality over purity in appropriate
ways, in a very Pythonic fashion. I confess to feeling that the
suggested changes are being proposed by those who have never actually
tried to put path.py to use in practical code, though I'm sure that's
not the case for everyone making those suggestions.
Still, once again this doesn't seem a critical issue to me and I'm happy
with either approach, if it means Path gets accepted in the stdlib.
At the moment, I think about overriding certain string methods that make
absolutely no sense on a path and raising an exception from them.
That would seem reasonable. It seems best to be very tolerant about
what makes no sense, though istitle() would surely be one of those to
go first. Also capitalize() (in spite of what Windows Explorer seems to
do sometimes), center(), expandtabs(), ljust(), rjust(), splitlines(),
title(), and zfill(). Hmm... maybe not zfill() actually. I could
imagine an actual (if rare) use for that.
I'll look into it. What about iteration and indexing? Should it support
for element in path or for char in path or nothing?
.bytes() and friends have felt quite
friendly in actual use, and I suspect .read_file_bytes() will feel quite
unwieldy. Not a show-stopper however.
It has even been suggested to throw them out, as they don't have so much to
do with a path per se. When the interface is too burdened, we'll have less
chance to be accepted. Renaming these makes clear that they are not
operations
on the path, but on a file the path points to.
Here again I would claim the practicality over purity argument. When
one has a Path, it is very frequently because one intends to open a file
object using it and do reads and writes (obviously). Also very often,
the type of reading and writing one wants to do is an all at once type
of thing, as those methods support. They're merely a convenience, to
save one doing the Path(xxx).open('rb').read thing when one can merely
do Path(xxx).bytes(), in much the same way that the whole justification
for Path() is that it bundles useful and commonly used operations
together into one place.
Phillip J. Eby suggested these to be set_file_xxx and get_file_xxx to
demonstrate
that they do not read or write a stream; how about that?
If they are there, they do exactly what they do, don't they? And they
do file.read() and file.write() operations, with slight nuances in the
mode passed to open() or the way the data is manipulated. Why would one
want to hide that, making it even harder to tie these operations
together with what is really going on under the covers? I think the
existing names, or at least ones with _read_ and _write_ in them
somewhere are better than set/get alternatives.
Re: [path-PEP] Path inherits from basestring again
Reinhold Birkenfeld [EMAIL PROTECTED] wrote in message news:[EMAIL PROTECTED] I'll look into it. What about iteration and indexing? Should it support for element in path or for char in path or nothing? I frankly can't think of a use for iterating over the characters in the path, but I have a number of programs that check elements, iterate over them and index them (frequently backwards). I also like to know the number of elements, which seems to make sense as len(path). Again, the number of characters in the path seems to be utterly useless information - at least, I can't imagine a use for it. John Roth Reinhold -- http://mail.python.org/mailman/listinfo/python-list
Re: [path-PEP] Path inherits from basestring again
Reinhold Birkenfeld wrote:
[on comparing Paths and stings]
Do you have a use case for the comparison? Paths should be compared only
with other paths.
I can think of lots, though I don't know that I've used any in my
existing (somewhat limited) code that uses Path, but they all involve
cases where I would expect, if comparisons were disallowed, to just wrap
the string in a Path first, even though to me that seems like it should
be an unnecessary step:
if mypath.splitpath()[0] == 'c:/temp':
if 'tests' in mypath.dirs():
and lots of other uses which start by treating a Path as a string
first, such as by doing .endswith('_unit.py')
Any of these could be resolved by ensuring both are Paths, but then I'm
not sure there's much justification left for using a baseclass of
basestring in the first place:
if mypath.splitpath()[0] == Path('c:/temp'):
if Path('tests') in mypath.dirs():
Question: would this latter one actually work? Would this check items
in the list using comparison or identity? Identity would simply be
wrong here.
[on removing properties in favour of methods for volatile data]
My line of thought is that a path may, but does not need to refer to an
existing, metadata-readable file. For this, I think a property is not
proper.
Fair enough, though in either case an attempt to access that information
leads to the same exception. I can't make a strong argument in favour
of properties (nor against them, really).
What about iteration and indexing? Should it support
for element in path or for char in path or nothing?
As John Roth suggests, the former seems a much more useful thing to do.
The latter is probably as rarely needed as it is with regular strings
(which I believe is roughly never in Python).
[on .read_file_bytes() etc]
I think it is not exactly bad that these names are somehow outstanding,
as that demonstrates that something complex and special happens.
Point taken. What about ditching the file part, since it is redundant
and obvious that a file is in fact what is being accessed. Thus:
.read_bytes(), .read_text(), .write_lines() etc.
-Peter
--
http://mail.python.org/mailman/listinfo/python-list
Re: [path-PEP] Path inherits from basestring again
On Sat, 23 Jul 2005 17:51:31 -0600, John Roth wrote: I also like to know the number of elements, which seems to make sense as len(path). Again, the number of characters in the path seems to be utterly useless information - at least, I can't imagine a use for it. There are (were?) operating systems that could only deal with a maximum length for pathnames. If I recall correctly, and I probably don't, Classic Mac (pre-OS X) was limited to file names of 31 or fewer characters and no more than 250-odd for the entire pathname. At the very least, some file manager routines would work and some would not. If you are printing the pathname, you may care about the length so that you can truncate it: longname = C:\really\really\really\really\really\long\path\name.txt if len(longname) 30: # do magic here print C:\really\ ... \path\name.txt else: print longname -- Steven. -- http://mail.python.org/mailman/listinfo/python-list
