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
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
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 because that's
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:
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.
That
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 by some
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 used by
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 isn't any formal
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 users.
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'))
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
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:
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 want to
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
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:
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 particular
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 it
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
18 matches
Mail list logo
