[Python-Dev] Unipath package

Sun Jan 28 15:06:25 CET 2007

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 <sluggoster at gmail.com> 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 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 <sluggoster at gmail.com>
> _______________________________________________
> Python-Dev mailing list
> Python-Dev at python.org
> http://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe:
> http://mail.python.org/mailman/options/python-dev/thobes%40gmail.com
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.python.org/pipermail/python-dev/attachments/20070128/7299dcf1/attachment.html 