Re: Path as a dictionary tree key? (was Re: PEP on path module for standard library)

Here's an example of how path objects could possibly be used to store and retrieve data from tree_dictionary class. I used lists here in place of path objects, but I think path objects would be better. I think paths used this way creates a consistant way to access data stored in both interna

Re: Path as a dictionary tree key? (was Re: PEP on path module for standard library)

Brian Beck wrote: > Ron Adam wrote: > >> This give a more general purpose for path objects. Working out ways >> to retrieve path objects from a dictionary_tree also would be useful I >> think. I think a Tree class would also be a useful addition as well. >> >> Any thoughts on this? > > > I d

Re: Path as a dictionary tree key? (was Re: PEP on path module for standard library)

Ron Adam wrote: > This give a more general purpose for path objects. Working out ways to > retrieve path objects from a dictionary_tree also would be useful I > think. I think a Tree class would also be a useful addition as well. > > Any thoughts on this? I don't think this would be as useful

Path as a dictionary tree key? (was Re: PEP on path module for standard library)

I'm wondering if a class that acts as a interface to a tree data structure stored in a dictionary could also be useful as a base class for accessing filesystems, urls, and zip (or rar) files. Then a path object could then be used as a dictionary_tree key. This idea seems much more useful to m

Re: PEP on path module for standard library

Ron Adam wrote: > Bengt Richter wrote: > > > http://msdn.microsoft.com/workshop/networking/pluggable/overview/aplugprot_overviews_entry.asp. Qvx -- http://mail.python.org/mailman/listinfo/python-list

Re: PEP on path module for standard library

Peter Hansen wrote: > A scattered assortment of module-level global function names, and > builtins such as open(), make it extraordinarily difficult to do > effective and efficient automated testing with "mock" objects. I have been able to do this by inserting my own module-scope function that i

Re: PEP on path module for standard library

Bengt Richter wrote: > > > > Say, how about > > if Pathobject('gui://message_box/yn/continue > processing?').open().read().lower()!='y': > raise SystemExit, "Ok, really not continuing ;-)" > > An appropriate registered subclass for the given platform, returned when the > Patho

Re: PEP on path module for standard library

Sorry for the formatting of my first message; I haven't posted via Google Groups before. Reinhold Birkenfeld wrote: > > - Some way to pretty-print paths embedded in lists/dicts as strings. I > > have a > > .repr_as_str class attribute that toggles this. > > I think str() does its job nicely the

Re: PEP on path module for standard library

Peter Hansen wrote: > Reinhold Birkenfeld wrote: >> Mike Orr wrote: >>>- I saw in a thread that .name and .parent were removed. I use them >>>very frequently, along with .ext and .namebase. I don't want to call >>>methods for these. >> >> They are now named .basename and .directory. > > Reinhol

Re: PEP on path module for standard library

Reinhold Birkenfeld wrote: > Mike Orr wrote: >>- Who needs .open()? open(myPath) is fine. But it can stay for >>backward compatibility. > > Right. I think it's nice for people who like a more OO approach. There's one very good reason to use .open() on a Path object, and in fact it's a (for me)

Re: PEP on path module for standard library

Reinhold Birkenfeld wrote: > Mike Orr wrote: >>- I saw in a thread that .name and .parent were removed. I use them >>very frequently, along with .ext and .namebase. I don't want to call >>methods for these. > > They are now named .basename and .directory. Reinhold, is ".parent" now ".directory"

Re: PEP on path module for standard library

On Sat, 30 Jul 2005 14:43:27 +0200, Reinhold Birkenfeld wrote: >> Less important but non-controversial: >> >> - Path.tempfile(), Path.tempdir(): >> Create a temporary file using tempfile.mkstemp, tempfile.mkdtemp >> >> - Path.tempfileobject(): >> Create a temporary file object using tempfile.T

Re: PEP on path module for standard library

Mike Orr wrote: > The main changes I'd like to see in Path (some of these have been made > in Python CVS at nondist/sandbox/path/path.py) are: Thanks for the comments! They are greatly appreciated. > - When methods create path objects, use self.__class__() instead of > Path(). > This makes it

Re: PEP on path module for standard library

Michael Hoffman wrote: > I use path in more of my modules and scripts than any other third-party > module, and I know it will be very helpful when I no longer have to > worry about deploying it. Same here. An object-oriented path module is extremely useful, and makes one's code much less cluttere

Re: PEP on path module for standard library

Terry Reedy wrote: > for dir in pathobject: > if isdir(dir): cd(dir) > > *is*, in essence, what the OS mainly does with paths (after splitting the > string representation into pieces). That's why there is rarely a need to to it in Python code. > Directory walks also work with paths as sequenc

Re: PEP on path module for standard library

John Roth wrote: > However, a path as a sequence of characters has even less > meaning - I can't think of a use, while I have an application That's true. But the arguments for path objects as strings go more in the direction of using existing functions that expect strings. > where traversing a

Re: PEP on path module for standard library

On Sat, 23 Jul 2005 07:05:05 +1000, John Machin <[EMAIL PROTECTED]> wrote: >Daniel Dittmar wrote: >> Duncan Booth wrote: >> >>> I would have expected a path object to be a sequence of path elements >>> rather than a sequence of characters. >> >> >> Maybe it's nitpicking, but I don't think th

Re: PEP on path module for standard library

Peter Hansen wrote: > Just a note, though you probably know, that this is intended to be > written this way with path: > > >>> p / q > path(u'a/b/c/d') I know, but it really doesn't look right to me. I think that my fundamental problem with all of this is that by making path a subclass of str/

Re: PEP on path module for standard library

George Sakkis wrote: > "Andrew Dalke" <[EMAIL PROTECTED]> wrote: >>I think that the string representation of a path is so important that >>it *is* the path. > > There are (at least) two frequently used path string representations, > the absolute and the relative to the working directory. Which o

Re: PEP on path module for standard library

Michael Hoffman wrote: > Reinhold Birkenfeld wrote: > > Probably as Terry said: a path is both a list and a string. [...] > One way to divide this is solely based on path separators: > > ['c:', 'windows', 'system32:altstream', 'test.dir', > 'myfile.txt.zip:altstream'] I would argue that any prop

Re: PEP on path module for standard library

George Sakkis wrote: > That's why phone numbers would be a subset of integers, i.e. not every > integer would correspond to a valid number, but with the exception of > numbers starting with zeros, all valid numbers would be an integers. But it's that exception which violates the LSP. With numbers

Re: PEP on path module for standard library

"Andrew Dalke" <[EMAIL PROTECTED]> wrote: > [snipped] > > > Take for example the case where a PhoneNumber class is subclass > > of int. According to LSP, it is perfectly ok to add phone numbers > > together, subtract them, etc, but the result, even if it's a valid > > phone number, just doesn't ma

Re: PEP on path module for standard library

George Sakkis wrote: > Bringing up how C models files (or anything else other than primitive types > for that matter) is not a particularly strong argument in a discussion on > OO design ;-) While I have worked with C libraries which had a well-developed OO-like interface, I take your point. Stil

Re: PEP on path module for standard library

Scott David Daniels: > Isn't it even worse than this? > On Win2K & XP, don't the file systems have something to do with the > encoding? So D: (a FAT drive) might naturally be str, while C: > (an NTFS drive) might naturally be unicode. This is generally safe as Windows is using unicode inte

Re: PEP on path module for standard library

Peter Hansen wrote: > Practically everything that path does, with a few useful exceptions, is > a thin wrapper around the existing calls. If the implementation is easy to explain, it may be a good idea. OT: I just realized you can now type in "python -m this" at the command line, which is conv

Re: PEP on path module for standard library

"Andrew Dalke" <[EMAIL PROTECTED]> wrote: > George Sakkis wrote: > > You're right, conceptually a path > > HAS_A string description, not IS_A string, so from a pure OO point of > > view, it should not inherit string. > > How did you decide it's "has-a" vs. "is-a"? > > All C calls use a "char *" fo

Re: PEP on path module for standard library

Michael Hoffman wrote: > Peter Hansen wrote: > >> When files are opened through a "path" object -- e.g. >> path('name').open() -- then file.name returns the path object that was >> used to open it. > > Also works if you use file(path('name')) or open(path('name')). Since that's exactly what th

Re: PEP on path module for standard library

Michael Hoffman wrote: > John Roth wrote: > >> However, a path as a sequence of characters has even less >> meaning - I can't think of a use, while I have an application >> where traversing a path as a sequence of path elements makes >> perfect sense: I need to descend the directory structure, dir

Re: PEP on path module for standard library

Daniel Dittmar wrote: > Duncan Booth wrote: > >> I would have expected a path object to be a sequence of path elements >> rather than a sequence of characters. > > > Maybe it's nitpicking, but I don't think that a path object should be a > 'sequence of path elements' in an iterator context.

Re: PEP on path module for standard library

Peter Hansen wrote: >> Most prominent change is that it doesn't inherit from str/unicode >> anymore. >> I found this distinction important, because as a str subclass the Path >> object >> has many methods that don't make sense for it. > > On this topic, has anyone ask the original author (Jason

Re: PEP on path module for standard library

Reinhold Birkenfeld wrote: > Andrew Dalke wrote: > >>I disagree. I've tried using a class which wasn't derived from >>a basestring and kept running into places where it didn't work well. >>For example, "open" and "mkdir" take strings as input. There is no >>automatic coercion. > > Well, as a Pa

Re: PEP on path module for standard library

Andrew Dalke wrote: > Duncan Booth wrote: >> Personally I think the concept of a specific path type is a good one, but >> subclassing string just cries out to me as the wrong thing to do. > > I disagree. I've tried using a class which wasn't derived from > a basestring and kept running into plac

Re: PEP on path module for standard library

Peter Hansen wrote: > When files are opened through a "path" object -- e.g. > path('name').open() -- then file.name returns the path object that was > used to open it. Also works if you use file(path('name')) or open(path('name')). -- Michael Hoffman -- http://mail.python.org/mailman/listinfo

Re: PEP on path module for standard library

Scott David Daniels wrote: > Duncan Booth wrote: > >> BTW, does it matter at all in practical use that the base class of >> path varies between str and unicode depending on the platform? > > Isn't it even worse than this? > On Win2K & XP, don't the file systems have something to do with the > en

Re: PEP on path module for standard library

"Michael Hoffman" <[EMAIL PROTECTED]> wrote in message news:[EMAIL PROTECTED] >> on 22.07.2005 00:21 Michael Hoffman said the following: >>> Any Java hackers here want to tell us of the wonders of the Java Path >>> class? > Ah, here it is: > > http://java.sun.com/j2se/1.5.0/docs/api/java/io/File.

Re: PEP on path module for standard library

Hi, 2005/7/22, Michael Hoffman <[EMAIL PROTECTED]>: > What is this Java Path class? I have been STFWing and have found nothing > on it in the. Indeed if you search for "Java Path class" (with quotes) > almost half of the pages are this message from Guido. ;) > > Any Java hackers here want to tell

Re: PEP on path module for standard library

Reinhold Birkenfeld wrote: > FYI: I modified the path module a bit so that it fits many of the suggestions > from python-dev, and put the result in the Python CVS tree under > nondist/sandbox/path. By the way, thanks for doing this Reinhold! > Most prominent change is that it doesn't inherit from

Re: PEP on path module for standard library

Duncan Booth wrote: > As I said elsewhere I haven't > used path for anything real, so I'm still finding surprises such as why > this doesn't do what I expect: > p = path('a/b') q = path('c/d') p+q > > path(u'a/bc/d') Just a note, though you probably know, that this is intended to b

Re: PEP on path module for standard library

Stefan Rank wrote: > (It would be nice to get `path`(s) easily from a `file`, at the moment > there is only file.name if I'm not mistaken). When files are opened through a "path" object -- e.g. path('name').open() -- then file.name returns the path object that was used to open it. -Peter --

Re: PEP on path module for standard library

Duncan Booth wrote: > BTW, does it matter at all in practical use that the base class of path > varies between str and unicode depending on the platform? I haven't seen any problem. I confess I can't even imagine exactly what the problem might be, since they're both subclasses of basestring, a

Re: PEP on path module for standard library

"Daniel Dittmar" <[EMAIL PROTECTED]> wrote in message news:[EMAIL PROTECTED] > Duncan Booth wrote: >> I would have expected a >> path object to be a sequence of path elements rather than a sequence of >> characters. Glad I'm not the only oddball. > Maybe it's nitpicking, but I don't think tha

Re: PEP on path module for standard library

John Roth wrote: > However, a path as a sequence of characters has even less > meaning - I can't think of a use, while I have an application > where traversing a path as a sequence of path elements makes > perfect sense: I need to descend the directory structure, directory > by directory, looking

Re: PEP on path module for standard library

Duncan Booth wrote: > BTW, does it matter at all in practical use that the base class of path > varies between str and unicode depending on the platform? Isn't it even worse than this? On Win2K & XP, don't the file systems have something to do with the encoding? So D: (a FAT drive) might natural

Re: PEP on path module for standard library

George Sakkis wrote: > You're right, conceptually a path > HAS_A string description, not IS_A string, so from a pure OO point of > view, it should not inherit string. How did you decide it's "has-a" vs. "is-a"? All C calls use a "char *" for filenames and paths, meaning the C model file for the f

Re: PEP on path module for standard library

Duncan Booth wrote: > Personally I think the concept of a specific path type is a good one, but > subclassing string just cries out to me as the wrong thing to do. I disagree. I've tried using a class which wasn't derived from a basestring and kept running into places where it didn't work well.

Re: PEP on path module for standard library

Michael Hoffman wrote: > Here's some code I just wrote seconds ago to construct a path for a > scp upload: > > """ > DST_DIRPATH = path("host:~/destination") > RSS_EXT = "rss" > > dst_filenamebase = os.extsep.join([postcode.lower(), RSS_EXT]) > dst_filepath = DST_DIRPATH.joinpath(dst_filenamebas

Re: PEP on path module for standard library

"Daniel Dittmar" <[EMAIL PROTECTED]> wrote in message news:[EMAIL PROTECTED] > Duncan Booth wrote: >> I would have expected a path object to be a sequence of path elements >> rather than a sequence of characters. > > Maybe it's nitpicking, but I don't think that a path object should be a > 'seq

Re: PEP on path module for standard library

"Duncan Booth" <[EMAIL PROTECTED]> wrote in message news:[EMAIL PROTECTED] > > John Roth wrote: >> You have to start somewhere. One of the lessons that's beginning >> to seep into people's minds is that getting something that works >> out there is almost always preferable to (over) design by commi

Re: PEP on path module for standard library

Duncan Booth wrote: > I would have expected a > path object to be a sequence of path elements rather than a sequence of > characters. Maybe it's nitpicking, but I don't think that a path object should be a 'sequence of path elements' in an iterator context. This means that for element in pa

Re: PEP on path module for standard library

Peter Hansen wrote: > Duncan, are you another formerly non-user of path who has this opinion, > or have you already attempted to use path extensively in your code? I'm a currently non-user of path who would probably use it if it were in the standard library but so far have been satisfied to use

Re: PEP on path module for standard library

"Duncan Booth" <[EMAIL PROTECTED]> wrote: > Personally I think the concept of a specific path type is a good one, but > subclassing string just cries out to me as the wrong thing to do. In other > words, to me a path represents something in a filesystem, the fact that it > has one, or indeed sever

Re: PEP on path module for standard library

George Sakkis wrote: > Havind said that, I think > the choice between subclassing or not is going to be a > practicality-vs-purity decision. You're right, conceptually a path > HAS_A string description, not IS_A string, so from a pure OO point of > view, it should not inherit string. OTOH, people

Re: PEP on path module for standard library

on 22.07.2005 16:14 George Sakkis said the following: > "Duncan Booth" <[EMAIL PROTECTED]> wrote: > >>Personally I think the concept of a specific path type is a good one, but >>subclassing string just cries out to me as the wrong thing to do. In other >>words, to me a path represents something in

Re: PEP on path module for standard library

"Duncan Booth" <[EMAIL PROTECTED]> wrote in message news:[EMAIL PROTECTED] > George Sakkis wrote: > > > You should need an explicit call to convert a path to a string and that > forces you when passing the path to something that requires a string to > think whether you wanted the string relative,

Re: PEP on path module for standard library

"Duncan Booth" <[EMAIL PROTECTED]> wrote: > Personally I think the concept of a specific path type is a good one, but > subclassing string just cries out to me as the wrong thing to do. In other > words, to me a path represents something in a filesystem, the fact that it > has one, or indeed sever

Re: PEP on path module for standard library

Duncan Booth wrote: > Personally I think the concept of a specific path type is a good one, but > subclassing string just cries out to me as the wrong thing to do. In other > words, to me a path represents something in a filesystem, the fact that it > has one, or indeed several string representa

Re: PEP on path module for standard library

Reinhold Birkenfeld wrote: > Michael Hoffman wrote: >>What do you gain from removing these methods? A smaller dir()? > > It made sense to me at the time I changed this, although at the moment > I can't exactly recall the reasons. Along with some of the others (and as a fairly heavy user of "path"

Re: PEP on path module for standard library

>Having path descend from str/unicode is extremely useful since I can >then pass a path object to any function someone else wrote without >having to worry about whether they were checking for basestring. I use path.py from Jason to encapsulate a lot of the windows plattform specialities of path dea

Re: PEP on path module for standard library

> When you try to 'freeze' an application module, >and Jason's 'path' module is present in any of the directories that are >looked at by freeze's module finder (your app doesn't have to import >it), freeze goes into an infinite loop of imports, eventually getting a >'maximum recursion depth' except

Re: PEP on path module for standard library

[EMAIL PROTECTED] writes: > I really love Jason's 'path' module. Sadly, I've encountered a serious > problem with using it. When you try to 'freeze' an application module, > and Jason's 'path' module is present in any of the directories that are > looked at by freeze's module finder (your app do

Re: PEP on path module for standard library

Duncan Booth wrote: > You should need an explicit call to convert a path to a string and that > forces you when passing the path to something that requires a string to > think whether you wanted the string relative, absolute, UNC, uri etc. Egad. I'm not sure if that will really make people's li

Re: PEP on path module for standard library

George Sakkis wrote: >> Read literally, this says (at least to me) "I don't want to fix it >> because I don't think it's broke." > > Or rather "I prefer a single existing mediocre solution than two > solutions (even if the second was better)". > Except that he is open to persuasion, so the PEP h

Re: PEP on path module for standard library

"John Roth" <[EMAIL PROTECTED]> wrote: > "Reinhold Birkenfeld" <[EMAIL PROTECTED]> wrote > > He said, > > > > """ > > Whoa! Do we really need a completely different mechanism for doing the > > same stuff we can already do? The path module seems mostly useful for > > folks coming from Java who are

Re: PEP on path module for standard library

Reinhold Birkenfeld: > And it is much more "Pythonic" in my eyes. Though that word may be inaccurate > when it comes from someone else that Guido, I feel that endless chains of > '[os.path.join(os.path.join(z, "a"), x) for x in > os.path.listdir(os.path.join(z, "a") if os.path.isfile(os.path.join

Re: PEP on path module for standard library

"Reinhold Birkenfeld" <[EMAIL PROTECTED]> wrote: > > Why did Guido want a PEP? Is it because he likes the idea but > > feels the feature set needs to be examined a bit more by the wider > > community, or is it some other reason? > > He said, > > """ > Whoa! Do we really need a completely different

Re: PEP on path module for standard library

"Reinhold Birkenfeld" <[EMAIL PROTECTED]> wrote in message news:[EMAIL PROTECTED] > John Roth wrote: >> "Michael Hoffman" <[EMAIL PROTECTED]> wrote in message >> news:[EMAIL PROTECTED] >>> Many of you are familiar with Jason Orendorff's path module >>>

Re: PEP on path module for standard library

John Roth wrote: > "Michael Hoffman" <[EMAIL PROTECTED]> wrote in message > news:[EMAIL PROTECTED] >> Many of you are familiar with Jason Orendorff's path module >> , which is frequently >> recommended here on c.l.p. I submitted an RFE to add it t

!Re: PEP on path module for standard library

"Michael Hoffman" <[EMAIL PROTECTED]> wrote in message news:[EMAIL PROTECTED] > Many of you are familiar with Jason Orendorff's path module > , which is frequently > recommended here on c.l.p. I submitted an RFE to add it to the Python > standard

Re: PEP on path module for standard library

Michael Hoffman wrote: > [EMAIL PROTECTED] wrote: >> I really love Jason's 'path' module. Sadly, I've encountered a serious >> problem with using it. When you try to 'freeze' an application module, >> and Jason's 'path' module is present in any of the directories that are >> looked at by freeze's

Re: PEP on path module for standard library

Michael Hoffman wrote: > Reinhold Birkenfeld wrote: >> FYI: I modified the path module a bit so that it fits many of the suggestions >> from python-dev, and put the result in the Python CVS tree under >> nondist/sandbox/path. >> >> Most prominent change is that it doesn't inherit from str/unicode

Re: PEP on path module for standard library

Reinhold Birkenfeld wrote: > FYI: I modified the path module a bit so that it fits many of the suggestions > from python-dev, and put the result in the Python CVS tree under > nondist/sandbox/path. > > Most prominent change is that it doesn't inherit from str/unicode anymore. > I found this distin

Re: PEP on path module for standard library

Stefan Rank wrote: > on 22.07.2005 00:21 Michael Hoffman said the following: >> Any Java hackers here want to tell us of the wonders of the Java Path >> class? > > no such thing exists. > > there is only the `File` class that incorporates a little bit of the > `path` functionality and some of t

Re: PEP on path module for standard library

Michael Hoffman wrote: > Having path descend from str/unicode is extremely useful since I can > then pass a path object to any function someone else wrote without > having to worry about whether they were checking for basestring. I think > there is a widely used pattern of accepting either a bas

Re: PEP on path module for standard library

on 22.07.2005 00:21 Michael Hoffman said the following: > Reinhold Birkenfeld wrote: > >>John Roth wrote: >> >> >>>Why did Guido want a PEP? >> >>He said, >> >>""" >>Whoa! Do we really need a completely different mechanism for doing the >>same stuff we can already do? The path module seems mostly

Re: PEP on path module for standard library

I really love Jason's 'path' module. Sadly, I've encountered a serious problem with using it. When you try to 'freeze' an application module, and Jason's 'path' module is present in any of the directories that are looked at by freeze's module finder (your app doesn't have to import it), freeze go

Re: PEP on path module for standard library

Reinhold Birkenfeld wrote: > John Roth wrote: > >>Why did Guido want a PEP? > > He said, > > """ > Whoa! Do we really need a completely different mechanism for doing the > same stuff we can already do? The path module seems mostly useful for > folks coming from Java who are used to the Java Path

Re: PEP on path module for standard library

Reinhold Birkenfeld wrote: > Michael Hoffman wrote: > >>Having path descend from str/unicode is extremely useful since I can >>then pass a path object to any function someone else wrote without >>having to worry about whether they were checking for basestring. I think >>there is a widely used p

Re: PEP on path module for standard library

[EMAIL PROTECTED] wrote: > I really love Jason's 'path' module. Sadly, I've encountered a serious > problem with using it. When you try to 'freeze' an application module, > and Jason's 'path' module is present in any of the directories that are > looked at by freeze's module finder (your app does

Re: PEP on path module for standard library

"Reinhold Birkenfeld" <[EMAIL PROTECTED]> wrote in message news:[EMAIL PROTECTED] > Most prominent change is that it doesn't inherit from str/unicode > anymore. > I found this distinction important, because as a str subclass the Path > object > has many methods that don't make sense for it. Wh

Re: PEP on path module for standard library

FYI: I modified the path module a bit so that it fits many of the suggestions from python-dev, and put the result in the Python CVS tree under nondist/sandbox/path. Most prominent change is that it doesn't inherit from str/unicode anymore. I found this distinction important, because as a str subcl

Re: PEP on path module for standard library

Peter Hansen wrote: > Michael Hoffman wrote: >> For the PEP, do any of you have arguments for or against including path? >> Code samples that are much easier or more difficult with this class >> would also be most helpful. > > I believe the strongest argument for "path" can be made for how it > i

Re: PEP on path module for standard library

Michael Hoffman wrote: > For the PEP, do any of you have arguments for or against including path? > Code samples that are much easier or more difficult with this class > would also be most helpful. I believe the strongest argument for "path" can be made for how it integrates functionality which

PEP on path module for standard library

Many of you are familiar with Jason Orendorff's path module , which is frequently recommended here on c.l.p. I submitted an RFE to add it to the Python standard library, and Reinhold Birkenfeld started a discussion on it in python-dev