[Python-Dev] Unipath package
I finally finished my path package (Unipath) and put it in the Cheeseshop.
http://sluggo.scrapping.cc/python/unipath/
There's a Path class for pathname calculations, and a FSPath subclass
for filesystem calls. I'm hoping Path -- or something resembling it
-- will find its way into os.path in Python 2.6 or 3.0. FSPath is
full of convenience methods so it may not be everybody's cup of tea,
but perhaps something similar can go into Python in the farther future
Unipath is an early alpha release so the API may change as it gets
more real-world use. There's an extensive unittest suite, which
passes on Python 2.5 and 2.4.4 on Linux. Windows and Macintosh
testers are needed.
Following are highlights from the python-3000 discussion and deviations from it:
- Path subclasses unicode, or str if the platform can't handle
Unicode pathnames.
- FSPath subclasses Path. This allows you to do "from unipath import
FSPath as Path" and pretend there's only one class. I find this much
more convenient in applications, so you don't have to cast objects
back and forth between the classes. Also, it just became infeasable
not to let them inherit, because so many methods call other methods.
- Nevertheless, you can use Path alone and rest assured it will never
touch the filesystem. You can even use Path objects with os.*
functions if you are so heretically inclined. If Path is accepted
into the stdlib, FSPath will inherit it from there.
- I tried splitting FSPath into several mixins according to type of
operation, but the need for methods to call other methods in a
different category sabotaged that too. So FSPath proudly has about
fifty methods. (Path has 10 public methods and 4 properties.)
- The dirname property is called .parent. The basename property is
.name. The extension property is .ext. The name without extension is
.stem.
- .components() returns a list of directory components. The first
component is "/", a Windows drive root, a UNC share, or "" for a
relative path. .split_root() returns the root and the rest.
- PosixPath, NTPath, and MacPath are Path subclasses using a specific
path library. This allows you to express non-native paths and convert
paths. Passing a relative foreign path to a *Path constructor
converts it to the destination type. Passing an absolute foreign path
is an error, because there's no sane way to interpret "C:\\" on Posix
or "/" on Windows. I'm skeptical whether this non-native support is
really worth it, because .norm() and .norm_case() already convert
slashes to backslashes (which is what Talin really wanted to do --
have Posix paths in a config file and automatically convert them to
the native format). And if Python is going to drop Mac OS 9 soon then
MacPath is obsolete. So maybe this non-native path code will prove
less than useful and will be deleted. On the other hand, if someone
is burning to write a zippath or ftppath library, you can use it with
this.
- Setting Path.auto_norm to true will automatically normalize all
paths on construction. I'm not sure if this should be the default,
because normalizing may produce the wrong path (e.g., if it contains a
symlink). You can always pass norm=True or norm=False to the
constructor to enable/disable it.
- p.child("subdir", "grandkid") is Glyph's favorite "safe join" method
that prevents creating a path pointing above 'p'. You can use it as a
.joinpath if you don't mind this restriction. The constructor allows
multiple positional arguments, which are joined using os.path.join().
- Listing is p.listdir(pattern=None, filter=None, names_only=False).
This returns a non-recursive list of paths. If 'names_only' is true
it returns the same as os.listdir(). p.walk(pattern=None,
filter=None, top_down=True) is the recursive counterpart, yielding
paths. In both cases 'pattern' is a glob pattern, and 'filter' is one
of the constants (FILES, DIRS, LINKS, FILES_NO_LINKS, DIRS_NO_LINKS,
DEAD_LINKS) or a custom boolean function. I spent a lot of time going
back and forth between Orendorff's six listing methods and Raphael's
one, and finally decided on this, partly because I'm not satisfied
with how either Orendorff's class or Raphael's or os.walk() handle
symlinks -- sometimes you want to ignore the links and then iterate
them separately.
- .read_file(mode) and .write_file(content, mode) are a compromise
between Orendorff's seven methods and purists' desire for zero
methods.
- .mkdir(), .rmdir(), .rmtree(), .copy(), .copy_stat(), .copy_tree(),
and .move() are more fancy than their stdlib/Orendorff counterparts.
They silently succeed if the operation is already done, and have
arguments to smartly create/delete intermediate directories, etc.
- Two extra functions are in 'unipath.tools'. 'dict2dir' creates a
directory hierarchy modeled after a dict. 'dump_path' displays an
ASCII tree of a directory hierarchy, with file sizes and symlink
targets showing.
Enjoy! and please provide feedback.
--Mike Orr <[EMAIL PROTECTED]>
Re: [Python-Dev] Unipath package
Hi!
I am a MSc of Computer Engineering student from Sweden. A frequent reader of
python-3000, and an occasional reader of python-dev for about a year now. I
have wanted to get involved in the development of python for a while but
haven't found the time before. Now, when I'm in the process of trying to
figure out what project to do for my thesis, I have actually found myself
having more time than before. Therefore I thought that now is a better time
than never to get involved. After that compulsory first-post-introduction of
myself, lets get to the reason I choose to send the post at all.
I noticed that you wanted Mac OS tests, here are the test results from my
Mac OS X (10.4), running on an Intel Core Duo MacBook, using python 2.5:
FF...F
==
FAIL: test_absolute (__main__.TestCalculatingPaths)
--
Traceback (most recent call last):
File "./test.py", line 235, in test_absolute
eq(p1, p2)
AssertionError: FSPath('/private/tmp/tmpH9fppC/images') !=
FSPath('/tmp/tmpH9fppC/images')
==
FAIL: test_chdir_absolute_relative (__main__.TestCalculatingPaths)
--
Traceback (most recent call last):
File "./test.py", line 220, in test_chdir_absolute_relative
eq(FSPath.cwd(), self.d)
AssertionError: FSPath('/private/tmp/tmpRJzqbt') != FSPath('/tmp/tmpRJzqbt')
==
FAIL: test_relative (__main__.TestCalculatingPaths)
--
Traceback (most recent call last):
File "./test.py", line 240, in test_relative
eq(p, "images")
AssertionError: FSPath('../../../tmp/tmpdw9juF/images') != 'images'
--
Ran 58 tests in 1.587s
Please let me know if there are any further tests or improvements I could
help you with.
/Tobias
On 1/28/07, Mike Orr <[EMAIL PROTECTED]> wrote:
I finally finished my path package (Unipath) and put it in the Cheeseshop.
http://sluggo.scrapping.cc/python/unipath/
There's a Path class for pathname calculations, and a FSPath subclass
for filesystem calls. I'm hoping Path -- or something resembling it
-- will find its way into os.path in Python 2.6 or 3.0. FSPath is
full of convenience methods so it may not be everybody's cup of tea,
but perhaps something similar can go into Python in the farther future
Unipath is an early alpha release so the API may change as it gets
more real-world use. There's an extensive unittest suite, which
passes on Python 2.5 and 2.4.4 on Linux. Windows and Macintosh
testers are needed.
Following are highlights from the python-3000 discussion and deviations
from it:
- Path subclasses unicode, or str if the platform can't handle
Unicode pathnames.
- FSPath subclasses Path. This allows you to do "from unipath import
FSPath as Path" and pretend there's only one class. I find this much
more convenient in applications, so you don't have to cast objects
back and forth between the classes. Also, it just became infeasable
not to let them inherit, because so many methods call other methods.
- Nevertheless, you can use Path alone and rest assured it will never
touch the filesystem. You can even use Path objects with os.*
functions if you are so heretically inclined. If Path is accepted
into the stdlib, FSPath will inherit it from there.
- I tried splitting FSPath into several mixins according to type of
operation, but the need for methods to call other methods in a
different category sabotaged that too. So FSPath proudly has about
fifty methods. (Path has 10 public methods and 4 properties.)
- The dirname property is called .parent. The basename property is
.name. The extension property is .ext. The name without extension is
.stem.
- .components() returns a list of directory components. The first
component is "/", a Windows drive root, a UNC share, or "" for a
relative path. .split_root() returns the root and the rest.
- PosixPath, NTPath, and MacPath are Path subclasses using a specific
path library. This allows you to express non-native paths and convert
paths. Passing a relative foreign path to a *Path constructor
converts it to the destination type. Passing an absolute foreign path
is an error, because there's no sane way to interpret "C:\\" on Posix
or "/" on Windows. I'm skeptical whether this non-native support is
really worth it, because .norm() and .norm_case() already convert
slashes to backslashes (which is what Talin really wanted to do --
have Posix paths in a config file and automatically convert them to
the native format). And if Python is going to drop Mac OS 9 soon then
MacPath is obsolete. So maybe this non-native path code
Re: [Python-Dev] Unipath package
Mike Orr wrote:
> I finally finished my path package (Unipath) and put it in the Cheeseshop.
> http://sluggo.scrapping.cc/python/unipath/
>
Hello Mike,
Looking through the docs it looks like a great package. However, didn't
Guido (on this list anyway) rule that he wouldn't accept a solution
which subclassed a string type?
Michael Foord
> There's a Path class for pathname calculations, and a FSPath subclass
> for filesystem calls. I'm hoping Path -- or something resembling it
> -- will find its way into os.path in Python 2.6 or 3.0. FSPath is
> full of convenience methods so it may not be everybody's cup of tea,
> but perhaps something similar can go into Python in the farther future
>
> Unipath is an early alpha release so the API may change as it gets
> more real-world use. There's an extensive unittest suite, which
> passes on Python 2.5 and 2.4.4 on Linux. Windows and Macintosh
> testers are needed.
>
> Following are highlights from the python-3000 discussion and deviations from
> it:
>
> - Path subclasses unicode, or str if the platform can't handle
> Unicode pathnames.
>
> - FSPath subclasses Path. This allows you to do "from unipath import
> FSPath as Path" and pretend there's only one class. I find this much
> more convenient in applications, so you don't have to cast objects
> back and forth between the classes. Also, it just became infeasable
> not to let them inherit, because so many methods call other methods.
>
> - Nevertheless, you can use Path alone and rest assured it will never
> touch the filesystem. You can even use Path objects with os.*
> functions if you are so heretically inclined. If Path is accepted
> into the stdlib, FSPath will inherit it from there.
>
> - I tried splitting FSPath into several mixins according to type of
> operation, but the need for methods to call other methods in a
> different category sabotaged that too. So FSPath proudly has about
> fifty methods. (Path has 10 public methods and 4 properties.)
>
> - The dirname property is called .parent. The basename property is
> .name. The extension property is .ext. The name without extension is
> .stem.
>
> - .components() returns a list of directory components. The first
> component is "/", a Windows drive root, a UNC share, or "" for a
> relative path. .split_root() returns the root and the rest.
>
> - PosixPath, NTPath, and MacPath are Path subclasses using a specific
> path library. This allows you to express non-native paths and convert
> paths. Passing a relative foreign path to a *Path constructor
> converts it to the destination type. Passing an absolute foreign path
> is an error, because there's no sane way to interpret "C:\\" on Posix
> or "/" on Windows. I'm skeptical whether this non-native support is
> really worth it, because .norm() and .norm_case() already convert
> slashes to backslashes (which is what Talin really wanted to do --
> have Posix paths in a config file and automatically convert them to
> the native format). And if Python is going to drop Mac OS 9 soon then
> MacPath is obsolete. So maybe this non-native path code will prove
> less than useful and will be deleted. On the other hand, if someone
> is burning to write a zippath or ftppath library, you can use it with
> this.
>
> - Setting Path.auto_norm to true will automatically normalize all
> paths on construction. I'm not sure if this should be the default,
> because normalizing may produce the wrong path (e.g., if it contains a
> symlink). You can always pass norm=True or norm=False to the
> constructor to enable/disable it.
>
> - p.child("subdir", "grandkid") is Glyph's favorite "safe join" method
> that prevents creating a path pointing above 'p'. You can use it as a
> .joinpath if you don't mind this restriction. The constructor allows
> multiple positional arguments, which are joined using os.path.join().
>
> - Listing is p.listdir(pattern=None, filter=None, names_only=False).
> This returns a non-recursive list of paths. If 'names_only' is true
> it returns the same as os.listdir(). p.walk(pattern=None,
> filter=None, top_down=True) is the recursive counterpart, yielding
> paths. In both cases 'pattern' is a glob pattern, and 'filter' is one
> of the constants (FILES, DIRS, LINKS, FILES_NO_LINKS, DIRS_NO_LINKS,
> DEAD_LINKS) or a custom boolean function. I spent a lot of time going
> back and forth between Orendorff's six listing methods and Raphael's
> one, and finally decided on this, partly because I'm not satisfied
> with how either Orendorff's class or Raphael's or os.walk() handle
> symlinks -- sometimes you want to ignore the links and then iterate
> them separately.
>
> - .read_file(mode) and .write_file(content, mode) are a compromise
> between Orendorff's seven methods and purists' desire for zero
> methods.
>
> - .mkdir(), .rmdir(), .rmtree(), .copy(), .copy_stat(), .copy_tree(),
> and .move() are more fancy than their stdlib/Orendorff counterparts.
> They silently succeed if the op
Re: [Python-Dev] Unipath package
On 1/28/07, Michael Foord <[EMAIL PROTECTED]> wrote: > Mike Orr wrote: > > I finally finished my path package (Unipath) and put it in the Cheeseshop. > > http://sluggo.scrapping.cc/python/unipath/ > > > Hello Mike, > > Looking through the docs it looks like a great package. However, didn't > Guido (on this list anyway) rule that he wouldn't accept a solution > which subclassed a string type? To be easily useful as a third-party module, it needs to subclass str/unicode so you can pass it directly to something like open(). That inheritance could be dropped if the module was included in the stdlib, as long as the inclusion was also accompanied by appropriate modifications to open()/file() to allow Path objects. STeVe -- I'm not *in*-sane. Indeed, I am so far *out* of sane that you appear a tiny blip on the distant coast of sanity. --- Bucky Katt, Get Fuzzy ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Unipath package
On 1/28/07, Tobias Ivarsson <[EMAIL PROTECTED]> wrote: > I am a MSc of Computer Engineering student from Sweden. A frequent reader of > python-3000, and an occasional reader of python-dev for about a year now. I > have wanted to get involved in the development of python for a while but > haven't found the time before. Now, when I'm in the process of trying to > figure out what project to do for my thesis, I have actually found myself > having more time than before. Therefore I thought that now is a better time > than never to get involved. After that compulsory first-post-introduction of > myself, lets get to the reason I choose to send the post at all. Hi Tobias! You've got the first step in Python development -- reading python-dev. Now you just have to pick an interesting task from the dozens hinted on the list and do it. Of course, there are many tasks not on python-dev that are also worthwhile. Bugfixes in the Python core, adopting a package that lost its maintainer, being active in the SIGs, testing code (as you've just done) -- these are just a few things off the top of my head. Working on third-party libraries is just as legitimate as working on the core; both are needed. There are also non-technical needs like promoting/marketing Python. If you can make it to PyCon or EuroPython, you'll meet a lot of contacts you can potentially collaborate with. Laura Creighton lives in Sweden and is highly involved in Python activities; she would no doubt have some suggestions. If you can't locate her I can dig up her address. If you'd like to write me privately about your specific interests and talents in Python, I can try to steer you to a group that is working on that. > I noticed that you wanted Mac OS tests, here are the test results from my > Mac OS X (10.4), running on an Intel Core Duo MacBook, using python 2.5: Thanks for the results. The details of Unipath's code are outside the scope of python-dev so I'll respond privately. The issue here is what kind of path object would be suitable for the standard library in 2.x. Guido has said he's not convinced that any OO-based path class is necessarily superior to the existing functions, but left the door open to later consideration. The existing proposals were rejected for reasons the Guido didn't personally elaborate, but others channeling him speculated they were too monolithic: too many methods in one class, too many diverse kinds of methods in one class, and especially mixing pathname-calculation and filesystem-access methods undifferentiated in one class. There is general agreement that a pathname-calculation class is more needed than a filesystem-access class due to the nesting of pathname calculations in expressions, so a pathname-calculation class has a greater chance of acceptance. There's also the question of what can be put in Python 2.x vs 3.0. There's a parallel proposal to move the filesystem-access functions in os.path into os, and to move everything in shlib into os, possibly with changes. This has the greatest chance of acceptance in 2.x. A small os.path.Path class has a middling chance. The discussion has been hampered by the lack of released code. Only Orendorff's class has been widely used in production systems. The others have either never been used or only by their authors; they haven't made it to the Cheeseshop. Unipath is merely to say "Here's another way to do it; see if it works for you." Certainly the Path methods need more testing and use in the real world before they'd be ready for the stdlib. The FSPath methods are more experimental so I'd say they need a year of use before they can be considered sufficiently stable. -- Mike Orr <[EMAIL PROTECTED]> ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Unipath package
On 1/28/07, Steven Bethard <[EMAIL PROTECTED]> wrote: > On 1/28/07, Michael Foord <[EMAIL PROTECTED]> wrote: > > Mike Orr wrote: > > > I finally finished my path package (Unipath) and put it in the Cheeseshop. > > > http://sluggo.scrapping.cc/python/unipath/ > > > > > Hello Mike, > > > > Looking through the docs it looks like a great package. However, didn't > > Guido (on this list anyway) rule that he wouldn't accept a solution > > which subclassed a string type? > > To be easily useful as a third-party module, it needs to subclass > str/unicode so you can pass it directly to something like open(). > That inheritance could be dropped if the module was included in the > stdlib, as long as the inclusion was also accompanied by appropriate > modifications to open()/file() to allow Path objects. Character slicing and some other string methods are also immensely useful. Subclassing string allows you to get all of them at once, rather than leaving out the one that was not foreseen to be needed. I was formerly a fan of the tuple-component approach but somebody said it splits the path too early, makes too many platform-specific assumptions or something like that. In practice, you really do want a path compatible with string so you can pass it to any function (stdlib or third-party) that accepts a string path, without getting into cases where you have to cast it (str()). There's also the string/unicode problem in Python 2.x: if you call str() on a string containing non-ASCII characters, you get an exception, and it's not always possible to guarantee the string you got from some other code is safe. If the BDFL does not accept a string-based path class, it will still have a long happy life as a third-party library. -- Mike Orr <[EMAIL PROTECTED]> ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] [Python-3000] Unipath package
I dropped the Cc: of Python-3000, because I don't think this discussion falls under that mailing list's charter. As I understand it, the Python-3000 mailing list is for discussing the details of implementing Python 3000. "Stuff I'd like to see in Python 3000" doesn't go there, it goes to "Python-Ideas". One part of your message caught my eye: Passing an absolute foreign path is an error, because there's no sane way to interpret "C:\\" on Posix or "/" on Windows. There is in fact a /very/ sane way to interpret "/" on Windows: the root directory of the "current" drive. It's equivalent to "\". I guess it isn't widely known, but nearly all Windows APIs are agnostic about whether you use "\" or "/" as a directory separator. (The only exceptions I recall are the common dialog open / save file functions.) I'm a Windows programmer, and I frequently use "/". The fact that you don't understand this about how Windows paths work makes me nervous about your path library. For instance, did you correctly support local paths on explicit drives (e.g. "d:../foo")? /larry/ ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] [Python-3000] Unipath package
On 1/28/07, Larry Hastings <[EMAIL PROTECTED]> wrote:
> I dropped the Cc: of Python-3000, because I don't think this discussion
> falls under that mailing list's charter. As I understand it, the
> Python-3000 mailing list is for discussing the details of implementing
> Python 3000. "Stuff I'd like to see in Python 3000" doesn't go there, it
> goes to "Python-Ideas".
python-ideas didn't exist when this thread was started. :) I was just
giving a status report on existing issues we'd discussed on
python-3000. You're right that any future work in this area will
probably involve python-ideas. I'm waiting for Unipath to get some
use before re-raising the question of what direction we want the
stdlib to go. I also support the other proposal to move some
functions from os.path/shutil to os, which is being worked on.
> One part of your message caught my eye:
>
> Passing an absolute foreign path is an error, because there's no sane way
> to interpret "C:\\" on Posix or "/" on Windows.
> There is in fact a very sane way to interpret "/" on Windows: the root
> directory of the "current" drive. It's equivalent to "\".
That's one way to do it, but whether Unipath should presume this is
what the programmer wants is another issue. One can make an argument
either way. I found it appealing to categorically refuse to translate
absolute paths to a foreign system, and force the user to make the
path relative and explicitly attach it to a new root (or
subdirectory). "Explicit is better than implicit", as the Python
mantra goes. If this turns out to be a hassle for programmers, we can
always be more lenient later.
> I guess it isn't
> widely known, but nearly all Windows APIs are agnostic about whether you use
> "\" or "/" as a directory separator. (The only exceptions I recall are the
> common dialog open / save file functions.) I'm a Windows programmer, and I
> frequently use "/".
I've heard contradictory things about this. Some people say just use
"/" and be happy; others say you get into trouble sometimes because
it's not the Windows kernel that does this but the application or
function, so some applications support it and some don't. In
particular I've heard that "/" on the command line is handled by the
application, which may impose the DOS semantics ("option flag") rather
than "directory separator".
> The fact that you don't understand this about how Windows paths work makes
> me nervous about your path library. For instance, did you correctly support
> local paths on explicit drives (e.g. "d:../foo")?
I did use Windows regularly until 1998. I do remember drive-relative
paths. My question is, do people seriously use them anymore? In a
Python program? Specifying a drive-relative path or chdir'ing to it
should work. The one thing Unipath does is consider it absolute:
isabsolute() returns True, and .components() and .split_root() return
"d:" as the root of the filesystem -- which it is. Joining the
components produces the original path, which Windows should correctly
interpret. So I don't see the harm as treating it as absolute in my
model. Maybe it does create some hardship for Windows users, and
maybe I'll have to consider. But drive-relative paths are really an
intermediate level between absolute and relative, and the model has no
place for the relative drive specification. E.g.,
Path("../foo").components() => ["", "..", "foo"]
Path("C:\\foo").components() => ["C:\\", "foo"]
Path("C:../foo").components() => ["C:", "..", "foo"]
Strictly speaking, the last path is relative so the first element
should be "". But that would leave no place for the "C:" specifier,
which would either belongs at index 0.5 or in a special attribute.
Accommodating either would require changing the entire model to
accommodate an obscure Windows-only feature, even though the model
works quite well otherwise.
It may be that Unipath just isn't suitable for manipulating Windows
drive-relative paths, and making it do so would would mess up Unipath
too much. The former is for Windows users to decide; the latter is
for me to decide based on their input.
I have also dropped .drive, .unc, .splitdrive(), and .splitunc(). I
think .split_root() is robust enough for what people want to do. But
I may be wrong. If there's necessity for those methods/properties
I'll add them, but I don't want to add a bunch of legacy methods that
will rarely be called.
--
Mike Orr <[EMAIL PROTECTED]>
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] [Python-3000] Unipath package
On 1/28/07, Mike Orr <[EMAIL PROTECTED]> wrote:
> > Passing an absolute foreign path is an error, because there's no sane way
> > to interpret "C:\\" on Posix or "/" on Windows.
> > There is in fact a very sane way to interpret "/" on Windows: the root
> > directory of the "current" drive. It's equivalent to "\".
>
> That's one way to do it, but whether Unipath should presume this is
> what the programmer wants is another issue. One can make an argument
> either way.
The issue is that *maybe* the programmer wants to copy "/etc/mailcap"
on his Posix filesystem to "\etc\mailcap" on his Windows drive, but
should we assume this since \etc does not have the special status on
Windows that /etc does on Unix? Maybe we should raise an exception
because the programmer intended to copy it somewhere else and forgot
something. Nothing wrong with forcing him to say, "Yes, I really mean
'\'."
As for Posix-format paths in config files that should be translated to
the native NT, that sounds straightforward. These paths should be
relative to some platform-specific root, because "C:/etc/mailcap" is
certainly not the path you intend to use on all platforms. (Unix
would put it in the current directory, wherever that might be.) You
can create a Path("/foo/bar") on NT and use it. The only thing you
can't do is:
p = Path( PosixPath("/foo/bar") ) # Illegal for absolute paths
if Path != PosixPath.
--
Mike Orr <[EMAIL PROTECTED]>
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] [Python-3000] Unipath package
Larry Hastings wrote: > There is in fact a /very/ sane way to interpret "/" on Windows: the root > directory of the "current" drive. Whether that's sane or not is debatable -- it depends entirely on what the application and/or user expect. A Unix user is probably expecting "/foo" to be completely unambiguous, and might be surprised if it gets turned into a Windows path that's not. In any case, there's no obvious meaning when going the other way (i.e. translating "C:\" into a Unix path). So I think it's reasonable to say that translation of absolute paths is not supported in general. -- Greg Ewing, Computer Science Dept, +--+ University of Canterbury, | Carpe post meridiem! | Christchurch, New Zealand | (I'm not a morning person.) | [EMAIL PROTECTED] +--+ ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] [Python-3000] Unipath package
Mike Orr wrote: > The issue is that *maybe* the programmer wants to copy "/etc/mailcap" > on his Posix filesystem to "\etc\mailcap" on his Windows drive, That doesn't make sense. In order to do this, either the Windows file system must be mounted on the Unix system, in which case Unix paths are used for both, or the Unix file system must be mounted on the Windows system, in which case they're both Windows paths. In neither case is a conversion from Unix to Windows pathnames needed. -- Greg Ewing, Computer Science Dept, +--+ University of Canterbury, | Carpe post meridiem! | Christchurch, New Zealand | (I'm not a morning person.) | [EMAIL PROTECTED] +--+ ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Unipath package
Thanks everyone who sent Windows and Mac unittest reports. I've got enough of them now. 95% of the Windows errors are because I forgot to remove symlinks from the control values. The repr() problem is more mysterious: somehow one path is turning into unicode while the other isn't. The chmod error probably just needs some bits excluded from the comparision. The Mac errors have to do with the general temp directory being a symlink, and some paths being resolved while others aren't. I'll have to take that up with my Mac-loving colleagues. 0.1.1 will be in the Cheeseshop soon with fixed tests. -- Mike Orr <[EMAIL PROTECTED]> ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Unipath package
On 28 Jan, 06:30 pm, [EMAIL PROTECTED] wrote: >The discussion has been hampered by the lack of released code. Only >Orendorff's class has been widely used in production systems. The >others have either never been used or only by their authors; they >haven't made it to the Cheeseshop. Unipath is merely to say "Here's >another way to do it; see if it works for you." Certainly the Path >methods need more testing and use in the real world before they'd be >ready for the stdlib. The FSPath methods are more experimental so I'd >say they need a year of use before they can be considered sufficiently >stable. Mike is mistaken here; Twisted has a module, twisted.python.filepath, which has been used extensively in production as well as by other projects. You can see such a project here (just the first hit on google code search): http://www.google.com/codesearch?hl=en&q=+twisted+python+filepath+show:3PfULFjjkV4:Vyh6PbYbXnU:7_Cvpg7zWo4&sa=N&cd=30&ct=rc&cs_p=https://taupro.com/pubsvn/Projects/Xanalogica/ShardsKeeper/trunk&cs_f=shardskeeper.py#a0 and the source to the module itself here: http://twistedmatrix.com/trac/browser/trunk/twisted/python/filepath.py Twisted's filepath implementation also provides a zipfile implementation of the same interface, so that, for example, you can copy a directory in the filesystem and put it into a zipfile with the same function. We plan to eventually also include tarfile and in-memory implementations. Of course, I am FilePath's author, so I have a certain bias; but I think it would be well suited to the standard library, and I would be interested to hear any feedback on it, especially that which would make it unsuitable for inclusion. ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Problem with signals in a single threaded application
Greg Ewing schrieb:
> Correct me if I'm wrong, but what I got from the OP
> was that the current method does
Ok, I'm correcting you: This is not what the current
method does:
>
>if (is_tripped) {
> for each signal {
>if the signal has occurred, call its handler
> }
> is_tripped = 0;
>}
Instead, the current method does this:
if (!is_tripped)
return;
for each signal {
if the signal has occurred, call its handler
}
is_tripped = 0
> and the problem is that any setting of is_tripped that
> occurs in the midst of calling the handlers gets
> wiped out at the end.
>
> Changing this to
>
>while (is_tripped) {
> for each signal {
>if the signal has occurred, call its handler
> }
> is_tripped = 0;
>}
My proposal (wrap the for loop with another is_tripped
looo) would literally give
if (!is_tripped)
return;
while(is_tripped) {
for each signal {
if the signal has occurred, call its handler
}
}
is_tripped = 0
Of course, that doesn't make much sense as it gives
an infinite loop. You need to clear is_tripped somewhere,
and I thought clearing it before the for loop would
work
if (!is_tripped)
return;
while(is_tripped) {
is_tripped = 0;
for each signal {
if the signal has occurred, call its handler
}
}
> If you really care, you can make that a while instead
> of an if so that you don't have to wait until the next
> CheckSignals. But if the signal had arrived a few
> microseconds later you'd have to do that anyway, so
> I don't see it as a big deal.
Sure. However, it's not that the signal would occur
"randomly" a few microseconds later, but instead
occurs *in* the signal handler.
I think Python currently has some "guarantee" that
a signal handler will be called quickly: either the
signal gets tripped in a blocking system call, which
ought to abort the system call, or the interpreter
is executing byte codes, when it will check for
signals every nth instruction.
A signal can get delayed significantly if the
interpreter makes a blocking system call before
handling the signal. I think this can happen
even today (if there is a blocking call between
the signal and the nth instruction, the signal
may still get delayed). However, in this specific
case, I think the chance that that the signal
gets delayed is high, and the case can be easily
implemented to avoid that risk.
Regards,
Martin
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
