Re: [Python-Dev] Alternative path suggestion
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 it is similar in spirit to what you proposed, a path being treated as a tuple, without the separators. This only makes sense. Using this class solved some really annoying problems while working on a project where I developed on my Linux laptop and released on the client's Windows machines. (I wish I could contribute in a more participatory way, but I'm really really swamped.) Anyway, +1 for a path encapsulation that is not a string, and that abstracts case-sensitiveness and path separators automatically. cheers, On 5/7/06, Noam Raphael [EMAIL PROTECTED] wrote: 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 discussed. I now wrote there what I think, and quoted a few opinions from other posts. The posts by others are only a minority - what's written there currently is mostly what I think. I'm sorry for the inconvinience, but please go there and post your opinions (you can copy and paste from your emails, of course). I apologize first for not replying to each post, and second for only writing my opinions in the wiki. I simply write pretty slowly in English, and am already developing a growing sleep-hours deficit. I hope you forgive me. Have a good day, Noam ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/blais%40furius.ca -- Martin Blais Furius Python Training -- http://furius.ca/training/ ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Alternative path suggestion
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 discussed. I now wrote there what I think, and quoted a few opinions from other posts. The posts by others are only a minority - what's written there currently is mostly what I think. I'm sorry for the inconvinience, but please go there and post your opinions (you can copy and paste from your emails, of course). I apologize first for not replying to each post, and second for only writing my opinions in the wiki. I simply write pretty slowly in English, and am already developing a growing sleep-hours deficit. I hope you forgive me. Have a good day, Noam ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Alternative path suggestion
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 what we're familiar with using. There's no reason to write the platform-specific classes until we agree on an API; that would just be work down the drain. When the new classes are in the library, we can: (one or more) - Leave os.path.foo() alone because it works and most existing programs need it. The threading module doesn't really obsolete the thread module, it just provides a higher level, more convenient API. Similarly, I don't believe it's a given that a nice path object will obsolete the low level operations. When translating a shell script to Python (or vice versa), having access to the comparable low level operations would be of benefit. 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. Is it that much of a step to translate: Y=$(dirname $(dirname $X))/lib as y = Path(x).parent.parent + lib y = Path(x).parent.parent.join(lib) or whatever the syntax do jour is rather than y = os.path.join(os.path.dirname(os.path.dirname(x)), lib) ? -- Mike Orr [EMAIL PROTECTED] ([EMAIL PROTECTED] address is semi-reliable) ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Alternative path suggestion
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 because I have a . in my filename doesn't
necessarily mean I intend what follows to be
treated as an extension.
assert pth.basepath == HOMEDIR
assert pth.dirparts == ('foo', 'bar')
assert pth.nameparts == ('baz', 'tar', 'gz')
What if one of the dirparts contains a character
happening to match os.extsep? When you do
pth2 = pth[:-1], does it suddenly get split up
into multiple nameparts, even though it's actually
naming a directory rather than a file?
(This is not hypothetical -- it's a common convention
in some unix systems to use names like spam.d for
directories of configuration files.)
--
Greg
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Alternative path suggestion
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 seems like the best idea, because it gives the most flexibility for dealing with the quirks of different systems' pathname semantics. -- Greg ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Alternative path suggestion
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 applications.
Just because I have a . in my filename doesn't
necessarily mean I intend what follows to be
treated as an extension.
This is up to the application to find out or deduce. Python still needs a
proper support for this highly diffused conventions. I would say that *most* of
the files in my own hard-disk follow this convention (let's see: *.html, *.py,
*.sh, *.cpp, *.c, *.h, *.conf, *.jpg, *.mp3, *.png, *.txt, *.zip, *.tar, *.gz,
*.pl, *.odt, *.mid, *.so... ehi, I can't find a file which it doesn't follow
this convention). Even if you can have a Python file without extension, it
doesn't mean that an application should manually extract foo out of foo.py
just because you could also name it only foo.
assert pth.basepath == HOMEDIR
assert pth.dirparts == ('foo', 'bar')
assert pth.nameparts == ('baz', 'tar', 'gz')
What if one of the dirparts contains a character
happening to match os.extsep? When you do
pth2 = pth[:-1], does it suddenly get split up
into multiple nameparts, even though it's actually
naming a directory rather than a file?
(This is not hypothetical -- it's a common convention
in some unix systems to use names like spam.d for
directories of configuration files.)
Yes. And there is absolutely nothing wrong with it. Do you have in mind any
real-world case in which an algorithm is broken by the fact that splitext()
doesn't magically guess what's an extension and what is not? People coding
Python applications *know* that splitext() will split the string using the
rightmost dot (if any). They *know* it doesn't do anything more than that; and
that it does that on any path string, even those where the rightmost dot
doesn't indicate a real extension. They know it's not magical, in that it can't
try to guess whether it is a real extension or not, and so does the simple,
clear, mechanical thing: it splits on the right-most dot.
And even if they know this limitation (if you want to call it so, I call it
clear, consistent behaviour which applies to a not-always-consistently-used
convention), the function is still useful.
Giovanni Bajo
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Alternative path suggestion
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 some applications. Just because I have a . in my filename doesn't necessarily mean I intend what follows to be treated as an extension. This is an interesting point - I've been tinkering with this a bit (despite my best intentions about not getting distracted by the topic ;), and it's starting to look like treating directory paths and file paths identically poses significant problems for an object-oriented API. For example, appending a filename or a relative directory path to an existing directory path is fine (giving a filename or directory path as the result), but you can't do either to a filename. Listing the entries or walking a file doesn't make any sense either. And extension information is typically significant only for filenames, not for directories. When paths are just strings, the distinction doesn't matter because the instances have no inherent behaviour - it is the application that carries the state regarding whether something is meant to be a directory name or a file name. So it makes a lot more sense to have separate Dirpath and Filepath (and possibly Linkpath) objects - from an OO point of view, the methods provided for each of these kinds of filesystem entities will be significantly different. A common parent Path object may still make sense if there's sufficient overlap, though (e.g. retrieving status related information). Cheers, Nick. -- Nick Coghlan | [EMAIL PROTECTED] | Brisbane, Australia --- http://www.boredomandlaziness.org ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Alternative path suggestion
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 notion of an extension, just a convention used by some applications. Just because I have a . in my filename doesn't necessarily mean I intend what follows to be treated as an extension. Good points, Nick and Greg. Splitting directories is unambiguous and makes the API much simpler. But filename extensions are just a convention. The user may want all, some, or no extensions split. With os.splitext() the user is explicitly saying, Split this number of extensions on this particular file. We we should not presume to automate this. How about: .splitext(max_exts=1)= (filename, list_of_extensions) Another good idea yesterday: p.parent(2) # Fulfills my .ancestor() proposal. This is an interesting point - I've been tinkering with this a bit (despite my best intentions about not getting distracted by the topic ;), and it's starting to look like treating directory paths and file paths identically poses significant problems for an object-oriented API. For example, appending a filename or a relative directory path to an existing directory path is fine (giving a filename or directory path as the result), but you can't do either to a filename. Listing the entries or walking a file doesn't make any sense either. And extension information is typically significant only for filenames, not for directories. When paths are just strings, the distinction doesn't matter because the instances have no inherent behaviour - it is the application that carries the state regarding whether something is meant to be a directory name or a file name. So it makes a lot more sense to have separate Dirpath and Filepath (and possibly Linkpath) objects - from an OO point of view, the methods provided for each of these kinds of filesystem entities will be significantly different. A common parent Path object may still make sense if there's sufficient overlap, though (e.g. retrieving status related information). Very interesting. The user knows whether he wants a file or directory, so why not force him to specify? Then we can have a standard exception if the actual filesystem object is inconsistent with the spec. -- Mike Orr [EMAIL PROTECTED] ([EMAIL PROTECTED] address is semi-reliable) ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Alternative path suggestion
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.
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
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Alternative path suggestion
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'))
AFAIK there is no way to escape path-splitting characters (directory
separators, actually) on any major platform.
Oleg.
--
Oleg Broytmannhttp://phd.pp.ru/[EMAIL PROTECTED]
Programmers don't die, they just GOSUB without RETURN.
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Alternative path suggestion
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 being able to name it. -- Greg ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Alternative path suggestion
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://python.pastebin.com/ /F ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Alternative path suggestion
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 manipulate paths that are not for the currently running OS. Therefore I think the `sep` should be an attribute of the root element. I meant to mention that. The idea I had was for normal path objects to use os.sep and os.extsep (so they can be pickled and unpickled successfully between platforms), and then have a mechanism that allowed a platform specific path to be selected based on the desired platform (i.e. one of the possible values of os.name: 'posix', 'nt', 'os2', 'mac', 'ce' or 'riscos'). 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 specifying the separators explicitly). That way the main class can avoid being complicated by the relatively rare need to operate on another platform's paths, while still supporting the ability. Cheers, Nick. -- Nick Coghlan | [EMAIL PROTECTED] | Brisbane, Australia --- http://www.boredomandlaziness.org ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Alternative path suggestion
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 specifying the separators explicitly). That way the main class can avoid being complicated by the relatively rare need to operate on another platform's paths, while still supporting the ability. You ought to have predefined classes for the standard OSes. Expecting people to know the values for sep and extsep seems unhelpful. In fact, unless you expect to support the os.path interface forever, as well as the new interface, I'd assume there would have to be internal WindowsPath and PosixPath classes anyway - much like the current ntpath and posixpath modules. So keeping that structure, and simply having if os.name == 'posix': Path = PosixPath elif os.name == 'nt': Path = WindowsPath ... etc at the end, would seem simplest. (But all the current proposals seem to build on os.path, so maybe I should assume otherwise, that os.path will remain indefinitely...) Paul. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Alternative path suggestion
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 (supplying 'os' would just be a
shortcut to avoid specifying the separators explicitly).
That way the main class can avoid being complicated by the relatively rare
need to operate on another platform's paths, while still supporting the
ability.
You ought to have predefined classes for the standard OSes. Expecting
people to know the values for sep and extsep seems unhelpful.
I assume that having subclasses (at least for the different os
filesystem paths) is not necessary.
The sep and extsep that needs to be used is determined by the root of
the path.
The root, I suppose, is set when constructing the path from a string.
The ambiguous cases are relative paths and `p = path()`.
(Also think of the proposed URL root which normally would mandate '/' as
sep. Actually, the format depends on the 'scheme' part of the URL...)
On the output side ( `str(pathinstance)` ) the format is determined by
the root.
At least if you ignore people who want to have
C:/this/style/of/acceptable/windows/path
When constructing a relative path, I suggest creating a os dependent one
(root==None) by default, even if you use::
p = path('./unix/relative/style')
on Windows.
Daring people can later use::
p.root = path.WINDOWSRELATIVE# or
p.root = path.UNIXRELATIVE
if they need to.
stefan
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Alternative path suggestion
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 use case. FWIW, subclassing tuple isn't any better in my book than subclassing str/unicode. My only other comment on this discussion: I don't really have time for it; but don't let that stop you all from having a jolly good time. If you need me to pronounce on something, put me (and python-dev) in the To: header and limit your post to 20 lines. -- --Guido van Rossum (home page: http://www.python.org/~guido/) ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Alternative path suggestion
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 as an internal representation.
{{{
p.normpath() - Isn't needed - done by the constructor
p.basename() - p[-1]
p.splitpath() - (p[:-1], p[-1])
p.splitunc() - (p[0], p[1:]) (if isinstance(p[0], path.UNCRoot))
p.splitall() - Isn't needed
p.parent - p[:-1]
p.name- p[-1]
p.drive - p[0] (if isinstance(p[0], path.Drive))
p.uncshare- p[0] (if isinstance(p[0], path.UNCRoot))
and of course:
p.join(q) [or anything like it] - p + q
}}}
Nice indeed.
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 functions accept a path
object.
Let's use __path_.. I mean, generic functions! ;-)
(...)
* A ''relative path'' is a path without a root element, so it can be
concatenated to other paths.
* An ''absolute path'' is a path whose meaning doesn't change when
the current working directory changes.
That sounds right.
== Easier attributes for stat objects ==
The current path objects includes:
* isdir, isfile, islink, and -
* atime, mtime, ctime, size.
(...)
This indeed shouldn't be attributes of path, IMO, since they are
operations that depend on the state of the filesystem, and will
change behind your back.
I think that isfile, isdir should be kept (along with lisfile,
lisdir), since I think that doing what they do is quite common, and
requires six lines:
I don't agree. isdir is an attribute of the filesystem, not of
the path object. I'd never expect that e.g. a network operation
could result from accessing an attribute in Python, and that could
certainly happen if the path is referencing a network filesystem.
--
Gustavo Niemeyer
http://niemeyer.net
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Alternative path suggestion
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://niemeyer.net ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
