Ron Adam wrote:
Bengt Richter wrote:
indulging what=my penchant for seeking the general behind the specific
;-)
There is a thing called Asynchronous pluggable protocol. It is
Microsoft's technology (don't flame me now):
Asynchronous pluggable protocols enable developers to create
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
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 as
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 don't think
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
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
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
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.TemporaryFile.
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? Does that
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)
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.
Reinhold, is .parent now
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 there.
Bengt Richter wrote:
indulging what=my penchant for seeking the general behind the specific ;-)
fold
Say, how about
if Pathobject('gui://message_box/yn/continue
processing?').open().read().lower()!='y':
raise SystemExit, Ok, really not continuing ;-)
An appropriate
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 cluttered.
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
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 sequences
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 make sense.
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,
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 proposed
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 one
*is*
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/unicode
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 that a path object
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
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 useful for
folks coming
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
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 the python
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 distinction
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 anymore.
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 module
John Roth wrote:
Michael Hoffman [EMAIL PROTECTED] wrote in message
news:[EMAIL PROTECTED]
Many of you are familiar with Jason Orendorff's path module
http://www.jorendorff.com/articles/python/path/, which is frequently
recommended here on c.l.p. I submitted an RFE to add it to the Python
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(
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 used to the Java Path
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 has to
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
[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
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' exception.
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
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
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 several
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,
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 a
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 in
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 several
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
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
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 committee.
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
'sequence of
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_filenamebase)
With
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.
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
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 naturally
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 for
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 that a path
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,
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 be
written this
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
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 us of
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.html
Very
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
encoding?
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
--
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 places
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 Path object
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 Orendorff)
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.
This
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, directory
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 the path
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 * for filenames and
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
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
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.
Still,
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,
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
integrates
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
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.
While I am
[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 doesn't
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 pattern of
76 matches
Mail list logo
