Ned Deily <n...@acm.org> added the comment:
The macpath module in the standard library purports to supply "the Mac OS 9
(and earlier) implementation of the os.path module. It can be used to
manipulate old-style Macintosh pathnames on Mac OS X (or any other platform).
The following functions are available in this module: normcase(), normpath(),
isabs(), join(), split(), isdir(), isfile(), walk(), exists(). For other
functions available in os.path dummy counterparts are available."
Old-style Mac pathnames are not further documented - in fact, the above quote
is the entire external documentation for the module - but they are ones using
colon separators, like ("MacHD:Users:nad:macpath_test:file"). These style path
names were initially supported on Mac OS X by compatibility APIs for programs
ported from classic Mac OS but those interfaces have long been deprecated in OS
X and in most cases are not available in 64-bit execution mode.
Even if one did have a need to use the obsolete old-style paths, the macpath
module is currently practically unusable for anything other than simple
character manipulations of the path. Nearly all of the functions that actually
call OS routines are broken in one or more ways.
Those that do make file system calls are calling APIs that are expecting normal
posix-style ('/' separated paths) incorrectly with old-style (":) paths
(ispath, isdir, lexists, etc) which means they only give correct results in the
trivial case of unqualified file or directory names, i.e. those in the working
directory.
The islink() function confusingly is testing whether a path points to a Finder
Alias file (not a symlink). Unfortunately, the Carbon API used for that test
does not exist in a 64-bit version and all of the Python Carbon modules were
removed in Python 3.
$ arch -i386 python2.7 -c 'import macpath;
print(macpath.islink("alias_to_file"))'
1
$ arch -x86_64 python2.7 -c 'import macpath;
print(macpath.islink("alias_to_file"))'
False
$ python3.2 -c 'import macpath; print(macpath.islink("alias_to_file"))'
False
The underlying import errors are being masked by "try"'s:
$ arch -i386 python2.7 -c 'import Carbon.File; Carbon.File.ResolveAliasFile'
$ arch -x86_64 python2.7 -c 'import Carbon.File; Carbon.File.ResolveAliasFile'
Traceback (most recent call last):
File "<string>", line 1, in <module>
AttributeError: 'module' object has no attribute 'ResolveAliasFile'
$ python3.2 -c 'import Carbon.File; Carbon.File.ResolveAliasFile'
Traceback (most recent call last):
File "<string>", line 1, in <module>
ImportError: No module named Carbon.File
The realpath function is also broken in 2.7, calling
Carbon.File.FSResolveAliasFile with a ":" separated path when it expects a "/"
path, and is totally broken in 3.x (no Carbon modules).
While macpath *could* be repaired by proper documentation, fixing the mishmash
of path types internally, and supplying C wrappers and/or alternative 64-bit
APIs, it does not seem worth the effort as these style paths are seldom
encountered in modern code. Considering how broken the module currently is and
given that it probably was simply overlooked in the Python 2 to 3 transition, I
think a case could be made for immediate removal prior to Python 3.2 release
and even for a 3.1.x maintenance release. Short of that, it should be cleared
documented as deprecated in 3.2, 3.1, and 2.7 along with warnings about broken
functionality along with added DeprecationWarnings to the module.
I can write up patches to do that depending on what the consensus is.
----------
_______________________________________
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/issue9850>
_______________________________________
_______________________________________________
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
