Unfortunately, I have no time to read all the details on this
interesting thread (I wish), but I also have an alternative path
implementation, feel free to scavenge anything from it you might find
useful. I put it here:
http://furius.ca/pubcode/pub/conf/common/lib/python/ipath.py.html
I think i
Hello all again!
Thanks to Mike's suggestion, I now opened a new wiki page,
AlternativePathDiscussion, in
http://wiki.python.org/moin/AlternativePathDiscussion
The idea is to organize the discussion by dividing it into multiple
sections, and seeing what is agreed and what should be further
discus
Edward Loper wrote:
> If one of the path segments contained a path-splitting character,
> should it automatically get quoted?
No, an exception should be raised if you try to construct
a Path object containing such a name. No such object could
exist in the file system, so there's no point in bei
Hello all,
I just wanted to say thanks for your encouraging comments and
participation, and to say that I'm sorry that I haven't replied yet -
unfortunately, I don't have an Internet connection where I stay most
evenings. I now read all your replies, but I want to reply seriously
and the time is g
On Sat, May 06, 2006 at 12:11:59PM -0400, Edward Loper wrote:
> If one of the path segments contained a path-splitting character,
> should it automatically get quoted? (Is that even possible on all
> platforms?) E.g., what would the following give me on windows?
>
> str(Path('a', 'b\\c'))
On May 6, 2006, at 2:40 AM, Nick Coghlan wrote:
> Remember, the idea with portable path information is to *never*
> store os.sep
> and os.extsep anywhere in the internal data - those should only be
> added when
> needed to produce strings to pass to OS-specific functions or to
> display to us
On 5/6/06, Nick Coghlan <[EMAIL PROTECTED]> wrote:
> Greg Ewing wrote:
> > Nick Coghlan wrote:
> >
> >> So I suggest splitting the internal data into 'path elements separated
> >> by os.sep', 'name elements separated by os.extsep'
> >
> > What bothers me about that is that in many systems
> > there
Greg Ewing wrote:
> Nick Coghlan wrote:
>
>> So I suggest splitting the internal data into 'path elements separated
>> by os.sep', 'name elements separated by os.extsep'
>
> What bothers me about that is that in many systems
> there isn't any formal notion of an "extension",
> just a convention
Greg Ewing <[EMAIL PROTECTED]> wrote:
>> So I suggest splitting the internal data into 'path elements
>> separated by os.sep', 'name elements separated by os.extsep'
>
> What bothers me about that is that in many systems
> there isn't any formal notion of an "extension",
> just a convention used b
Mike Orr wrote:
> How do you do slicing and joining? If Path subclasses object, it
> could be done there like in the first example. But if Path subclasses
> string,
Er, hang on, I thought the idea was that it wouldn't
subclass either tuple *or* str, but would be a new
class all of its own.
Tha
Nick Coghlan wrote:
> So I suggest splitting the internal data into 'path elements separated
> by os.sep', 'name elements separated by os.extsep'
What bothers me about that is that in many systems
there isn't any formal notion of an "extension",
just a convention used by some applications.
Just
Mike Orr wrote:
> There's something that bothers me about putting the path in an
> attribute rather than subclassing tuple.
[...]
> How do you do slicing and joining? If Path subclasses object, it
> could be done there like in the first example. But if Path subclasses
> string, that API is taken:
There's something that bothers me about putting the path in an
attribute rather than subclassing tuple. I prefer it that way but I
don't see how you'd do directory slicing and joining. If the path is
a tuple it's easy:
p = Path("/a/b/c")
p[:-1] # Path("/a/b")
If the directory components
Mike Orr wrote:
> I think you meant to say Perl in that sentence. In Python there
> should be one way to do it, and beautiful is better than ugly. The
> os.path functions are bad enough, but shutil.copy2 is just plain evil.
I agree a decent pathlib may make many of the low-level filesystem
mani
[Nick]
>>> Similarly, I would separate out the extension to a distinct
>>> attribute, as it too uses a different separator from the normal path
>>> elements ('.' most places, but '/' on RISC OS, for example)
[Greg]
>> -1. What constitutes "the extension" is not well-defined in
>> all cases. What a
On 5/5/06, Nick Coghlan <[EMAIL PROTECTED]> wrote:
> Mike Orr wrote:
> > On 5/4/06, Paul Moore <[EMAIL PROTECTED]> wrote:
> >> (But all the current proposals seem to build on os.path, so maybe I
> >> should assume otherwise, that os.path will remain indefinitely...)
> >
> > They build on os.path be
Greg Ewing <[EMAIL PROTECTED]> wrote:
>> Similarly, I would separate out the extension to a distinct
>> attribute, as it too uses a different separator from the normal path
>> elements ('.' most places, but '/' on RISC OS, for example)
>
> -1. What constitutes "the extension" is not well-defined i
Noam Raphael <[EMAIL PROTECTED]> wrote:
> The only drawback I can see in using a logical representation is that
> giving a path object to functions which expect a path string won't
> work. The immediate solution is to simply use str(p) instead of p. The
> long-term solution is to make all related
Mike Orr wrote:
> On 5/4/06, Paul Moore <[EMAIL PROTECTED]> wrote:
>> (But all the current proposals seem to build on os.path, so maybe I
>> should assume otherwise, that os.path will remain indefinitely...)
>
> They build on os.path because that's what we're familiar with using.
> There's no rea
On 5/4/06, Paul Moore <[EMAIL PROTECTED]> wrote:
> On 5/4/06, Nick Coghlan <[EMAIL PROTECTED]> wrote:
> > My inclination was to have a PlatformPath subclass that accepted 'os', 'sep'
> > and 'extsep' keyword arguments to the constructor, and provided the
> > appropriate 'sep' and 'extsep' attribute
On 5/4/06, Nick Coghlan <[EMAIL PROTECTED]> wrote:
> Mike Orr wrote:
> >> == a tuple instead of a string ==
> >>
> >> The biggest conceptual change is that my path object is a subclass of
> >> ''tuple'', not a subclass of str.
>
> Why subclass anything? The path should internally represent the file
I've updated the wiki with a second proposal based on this thread, and
also summarized the Python-dev discussions. Please make sure your
favorite feature or pet peeve is adequately represented.
http://wiki.python.org/moin/AlternativePathClass
--
Mike Orr <[EMAIL PROTECTED]>
([EMAIL PROTECTED] ad
Nick Coghlan wrote:
> Similarly, I would separate out the extension to a distinct attribute, as it
> too uses a different separator from the normal path elements ('.' most
> places,
> but '/' on RISC OS, for example)
-1. What constitutes "the extension" is not well-defined in
all cases. What a
Mike Orr wrote:
> The main difficulty with this approach is it's so radical. It would
> require a serious champion to convince people it's as good as our
> tried-and-true strings.
Another thing you would need to do is implement it for
some of the less Unix-like path syntaxes, such as Classic
Mac
Guido van Rossum wrote:
> On 5/4/06, Nick Coghlan <[EMAIL PROTECTED]> wrote:
>> Guido has indicated strong dissatisfaction with the idea of subclassing
>> str/unicode with respect to PEP 355.
>
> That's not my only problem with that PEP; I'm not at all convinced
> that an object is a better soluti
"Mike Orr" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]
> Intriguing idea, Noam, and excellent thinking. I'd say it's worth a
> separate PEP.
I am glad to see this idea resurface and developed. So +1 on an alternate
PEP.
> The main difficulty with this approach is it's so radi
> You ought to have predefined classes for the standard OSes. Expecting
> people to know the values for sep and extsep seems unhelpful.
(...)
Why not something as simple as having path.sep == None meaning the
default for the platform, and a defined value for otherwise?
--
Gustavo Niemeyer
http:/
> The biggest conceptual change is that my path object is a subclass of
> ''tuple'', not a subclass of str. For example,
Using tuples is a nice idea! Object paths using tuples is a somewhat
common concept. I don't see an immediate reason to be a *subclass*
of tuple, though, as opposed to using i
On 5/4/06, Nick Coghlan <[EMAIL PROTECTED]> wrote:
> Guido has indicated strong dissatisfaction with the idea of subclassing
> str/unicode with respect to PEP 355.
That's not my only problem with that PEP; I'm not at all convinced
that an object is a better solution than a module for this particul
on 04.05.2006 16:18 Paul Moore said the following:
> On 5/4/06, Nick Coghlan <[EMAIL PROTECTED]> wrote:
>> My inclination was to have a PlatformPath subclass that accepted 'os', 'sep'
>> and 'extsep' keyword arguments to the constructor, and provided the
>> appropriate 'sep' and 'extsep' attributes
On 5/4/06, Nick Coghlan <[EMAIL PROTECTED]> wrote:
> My inclination was to have a PlatformPath subclass that accepted 'os', 'sep'
> and 'extsep' keyword arguments to the constructor, and provided the
> appropriate 'sep' and 'extsep' attributes (supplying 'os' would just be a
> shortcut to avoid spe
Stefan Rank wrote:
>> I suggest storing the first element separately from the rest of the path.
>> The
>> reason for suggesting this is that you use 'os.sep' to separate elements in
>> the normal path, but *not* to separate the first element from the rest.
>
> I want to add that people might wa
on 04.05.2006 14:57 Nick Coghlan said the following:
> Mike Orr wrote:
>> Intriguing idea, Noam, and excellent thinking. I'd say it's worth a
>> separate PEP. It's too different to fit into PEP 355, and too big to
>> be summarized in the "Open Issues" section. Of course, one PEP will
>> be rejec
Mike Orr wrote:
> Intriguing idea, Noam, and excellent thinking. I'd say it's worth a
> separate PEP. It's too different to fit into PEP 355, and too big to
> be summarized in the "Open Issues" section. Of course, one PEP will
> be rejected if the other is approved.
I agree that a competing PEP
Noam Raphael wrote:
> You can find the implementation at
> http://wiki.python.org/moin/AlternativePathModule?action=raw
> (By the way, is there some "code wiki" available? It can simply be a
> public svn repository. I think it will be useful for those things.)
pastebin is quite popular:
http
On 5/2/06, Noam Raphael <[EMAIL PROTECTED]> wrote:
> Here are my ideas. It's a copy of what I posted a few minutes ago in
> the wiki - you can view it at
> http://wiki.python.org/moin/AlternativePathClass (it looks better
> there).
>
> You can find the implementation at
> http://wiki.python.org/moi
Hello,
I saw the discussion about including the path type in the standard
library. As it turned out, I recently wrote a program which does quite
a lot of path manipulation. This caused me to think that the proposed
path module:
* Makes path manipulation significantly easier
* Can be improved.
37 matches
Mail list logo
