BJörn Lindqvist wrote:
> On 10/28/06, Talin <[EMAIL PROTECTED]> wrote:
>> BJörn Lindqvist wrote:
>> > I'd like to write a post mortem for PEP 355. But one important
>> > question that haven't been answered is if there is a possibility for a
>> > path-like PEP to succeed in the future? If so, does t
On 10/28/06, Talin <[EMAIL PROTECTED]> wrote:
> BJörn Lindqvist wrote:
> > I'd like to write a post mortem for PEP 355. But one important
> > question that haven't been answered is if there is a possibility for a
> > path-like PEP to succeed in the future? If so, does the path-object
> > implementa
BJörn Lindqvist wrote:
> I'd like to write a post mortem for PEP 355. But one important
> question that haven't been answered is if there is a possibility for a
> path-like PEP to succeed in the future? If so, does the path-object
> implementation have to prove itself in the wild before it can be
>
Talin wrote:
> It seems that any Python program that manipulated paths
> would have to be radically different in the environment that you describe.
I can sympathise with that. The problem is really
inherent in the nature of the platforms -- it's
just not possible to do everything in a native
clas
Greg Ewing wrote:
> Talin wrote:
>
>> That's true of textual paths in general - i.e. even on unix, textual
>> paths aren't guaranteed to be unique or exist.
>
> What I mean is that it's possible for two different
> files to have the same pathname (since you can mount
> two volumes with identical
Talin wrote:
> That's true of textual paths in general - i.e. even on unix, textual
> paths aren't guaranteed to be unique or exist.
What I mean is that it's possible for two different
files to have the same pathname (since you can mount
two volumes with identical names at the same time, or
for
On Oct 25, 2006, at 10:48 PM, Talin wrote:
> That's true of textual paths in general - i.e. even on unix, textual
> paths aren't guaranteed to be unique or exist.
>
> Its been a while since I used classic MacOS - how do you handle things
> like configuration files with path names in them?
You aren
Talin wrote:
> Ideally, you should be able to pass
> "file:///..." to a regular "open" function.
I'm not so sure about that. Consider that "file:///foo.bar"
is a valid relative pathname on Unix to a file called "foo.bar"
in a directory called "file:".
That's not to say there shouldn't be a funct
Greg Ewing wrote:
> Talin wrote:
>> (Actually, the OOP approach has a slight advantage in terms of the
>> amount of syntactic sugar available,
>
> Even if you don't use any operator overloading, there's
> still the advantage that an object provides a namespace
> for its methods. Without that, you
Talin wrote:
> (Actually, the OOP approach has a slight advantage in terms of the
> amount of syntactic sugar available,
Even if you don't use any operator overloading, there's
still the advantage that an object provides a namespace
for its methods. Without that, you either have to use
fairly ver
Talin wrote:
>> You probably want to use the posixpath module directly in that case,
>> though perhaps you've already discovered that.
>
> Never heard of it. Its not in the standard library, is it? I don't see
> it in the table of contents or the index.
http://effbot.org/librarybook/posixpath.
At 10:16 AM 10/25/2006 -0700, Talin wrote:
>Phillip J. Eby wrote:
> > At 09:49 AM 10/25/2006 -0700, Talin wrote:
> >> Having done a path library myself (in C++, for our code base at work),
> >> the trickiest part is getting the Windows path manipulations right, and
> >> fitting them into a model th
On Wednesday 25 October 2006 13:16, Talin wrote:
> Never heard of it. Its not in the standard library, is it? I don't see
> it in the table of contents or the index.
This is a documentation bug. :-( I'd thought they were mentioned
*somewhere*, but it looks like I'm wrong.
os.path is an alias
Phillip J. Eby wrote:
> At 09:49 AM 10/25/2006 -0700, Talin wrote:
>> Having done a path library myself (in C++, for our code base at work),
>> the trickiest part is getting the Windows path manipulations right, and
>> fitting them into a model that allows writing of platform-agnostic code.
>> This
At 09:49 AM 10/25/2006 -0700, Talin wrote:
>Having done a path library myself (in C++, for our code base at work),
>the trickiest part is getting the Windows path manipulations right, and
>fitting them into a model that allows writing of platform-agnostic code.
>This is especially vexing when you r
Nick Coghlan wrote:
> Talin wrote:
>> Part 3: Does this mean that the current API cannot be improved?
>>
>> Certainly not! I think everyone (well, almost) agrees that there is
>> much room for improvement in the current APIs. They certainly need to
>> be refactored and recategorized.
>>
>> But I
Talin wrote:
> Part 3: Does this mean that the current API cannot be improved?
>
> Certainly not! I think everyone (well, almost) agrees that there is much
> room for improvement in the current APIs. They certainly need to be
> refactored and recategorized.
>
> But I don't think that the soluti
Scott Dial wrote:
> [EMAIL PROTECTED] wrote:
>> Talin writes:
>> > (one additional postscript - One thing I would be interested in is
>> an > approach that unifies file paths and URLs so that there is a
>> consistent > locator scheme for any resource, whether they be in a
>> filesystem, on a
Scott Dial writes:
> [EMAIL PROTECTED] wrote:
> > Talin writes:
> > > (one additional postscript - One thing I would be interested in is an
> > > approach that unifies file paths and URLs so that there is a consistent
> > > locator scheme for any resource, whether they be in a filesystem,
[EMAIL PROTECTED] wrote:
> Talin writes:
> > (one additional postscript - One thing I would be interested in is an
> > approach that unifies file paths and URLs so that there is a consistent
> > locator scheme for any resource, whether they be in a filesystem, on a
> > web server, or stored
[EMAIL PROTECTED] wrote:
> Talin writes:
> > (one additional postscript - One thing I would be interested in is an
> > approach that unifies file paths and URLs so that there is a consistent
> > locator scheme for any resource, whether they be in a filesystem, on a
> > web server, or stored
Talin writes:
> (one additional postscript - One thing I would be interested in is an
> approach that unifies file paths and URLs so that there is a consistent
> locator scheme for any resource, whether they be in a filesystem, on a
> web server, or stored in a zip file.)
+1
But doesn't fi
(one additional postscript - One thing I would be interested in is an
approach that unifies file paths and URLs so that there is a consistent
locator scheme for any resource, whether they be in a filesystem, on a
web server, or stored in a zip file.)
-- Talin
___
BJörn Lindqvist wrote:
> On 10/1/06, Guido van Rossum <[EMAIL PROTECTED]> wrote:
>> On 9/30/06, Giovanni Bajo <[EMAIL PROTECTED]> wrote:
>>> It would be terrific if you gave us some clue about what is wrong in
>>> PEP355, so
>>> that the next guy does not waste his time. For instance, I find PEP35
On 10/1/06, Guido van Rossum <[EMAIL PROTECTED]> wrote:
> On 9/30/06, Giovanni Bajo <[EMAIL PROTECTED]> wrote:
> > It would be terrific if you gave us some clue about what is wrong in
> > PEP355, so
> > that the next guy does not waste his time. For instance, I find PEP355
> > incredibly good for
On 9/30/06, Giovanni Bajo <[EMAIL PROTECTED]> wrote:
> Guido van Rossum wrote:
> > OK. Pronouncement: PEP 355 is dead. [...]
>
> It would be terrific if you gave us some clue about what is
> wrong in PEP355, [...]
Here are my guesses. I believe Guido rejected this PEP for a lot of reasons.
By th
On 9/30/06, Giovanni Bajo <[EMAIL PROTECTED]> wrote:
> It would be terrific if you gave us some clue about what is wrong in PEP355,
> so
> that the next guy does not waste his time. For instance, I find PEP355
> incredibly good for my own path manipulation (much cleaner and concise than
> the
> a
On Sun, 01 Oct 2006 13:56:53 +1000, Nick Coghlan <[EMAIL PROTECTED]> wrote:
>Things the PEP 355 path object lumps together:
> - string manipulation operations
> - abstract path manipulation operations (work for non-existent filesystems)
> - read-only traversal of a concrete filesystem (dir
Giovanni Bajo wrote:
> Guido van Rossum wrote:
>
>> OK. Pronouncement: PEP 355 is dead. The authors (or the PEP editor)
>> can update the PEP.
>>
>> I'm looking forward to a new PEP.
>
> It would be terrific if you gave us some clue about what is wrong in PEP355,
> so
> that the next guy does no
Guido van Rossum wrote:
> OK. Pronouncement: PEP 355 is dead. The authors (or the PEP editor)
> can update the PEP.
>
> I'm looking forward to a new PEP.
It would be terrific if you gave us some clue about what is wrong in PEP355, so
that the next guy does not waste his time. For instance, I find
OK. Pronouncement: PEP 355 is dead. The authors (or the PEP editor)
can update the PEP.
I'm looking forward to a new PEP.
--Guido
On 9/30/06, Michael Hudson <[EMAIL PROTECTED]> wrote:
> [EMAIL PROTECTED] writes:
>
> > I hope that eventually Python will include some form of OO
> > filesystem acce
[EMAIL PROTECTED] writes:
> I hope that eventually Python will include some form of OO
> filesystem access, but I am equally hopeful that the current PEP 355
> path.py is not it.
I think I agree with this too. For another source of ideas there is
the 'py.path' bit of the py lib, which, um, doesn
[EMAIL PROTECTED] wrote:
> I hope that eventually Python will include some form of OO filesystem
> access, but I am equally hopeful that the current PEP 355 path.py is not
> it.
+1
Cheers,
Nick.
--
Nick Coghlan | [EMAIL PROTECTED] | Brisbane, Australia
On Fri, 29 Sep 2006 12:38:22 -0700, Guido van Rossum <[EMAIL PROTECTED]> wrote:
>I would recommend not using it. IMO it's an amalgam of unrelated
>functionality (much like the Java equivalent BTW) and the existing os
>and os.path modules work just fine. Those who disagree with me haven't
>done a v
Shouldn't that paragraph be added to the PEP (e.g. under a "Status" subheading)?
enjoying-top-posting-ly,
Georg
Guido van Rossum wrote:
> I would recommend not using it. IMO it's an amalgam of unrelated
> functionality (much like the Java equivalent BTW) and the existing os
> and os.path modules
Thanks for your reply, that's the kind of info I was looking for to
decide what to do. Good enough, I'll move on then.
Thanks
--
Luis P Caamano
Atlanta, GA USA
On 9/29/06, Guido van Rossum <[EMAIL PROTECTED]> wrote:
> I would recommend not using it. IMO it's an amalgam of unrelated
> functiona
I would recommend not using it. IMO it's an amalgam of unrelated
functionality (much like the Java equivalent BTW) and the existing os
and os.path modules work just fine. Those who disagree with me haven't
done a very good job of convincing me, so I expect this PEP to remain
in limbo indefinitely,
What's the status of PEP 355, Path - Object oriented filesystem paths?
We'd like to start using the current reference implementation but we'd
like to do it in a manner that minimizes any changes needed when Path
becomes part of stdlib.
In particular, the reference implementation in
http://wiki.py
38 matches
Mail list logo
