On 4/21/2012 8:53 PM, Brett Cannon wrote:
imp.cache_from_source() (and thus also imp.source_from_cache()) has
special semantics compared to how os.path.join() works. For instance,
if you look at test_imp you will notice it tries to use the same path
separator as is the farthest right in the path it is given::
self.assertEqual(imp.cache_from_source('\\foo\\bar/baz/qux.py',
True), '\\foo\\bar\\baz/__pycache__/qux.{}.pyc'.format(self.tag))
But if you do the same basic operation using ntpath, you will notice
it simply doesn't care::
>>> ntpath.join(ntpath.split('a\\b/c/d.py')[0], '__pycache__',
'd.cpython-32.pyc')
'a\\b/c\\__pycache__\\d.cpython-32.pyc
Basically imp.cache_from_source() goes to a bunch of effort to reuse
the farthest right separator when there is an alternative separator
*before* and path splitting is done. But if you look at ntpath.join(),
it doesn't even attempt that much effort.
Now that we can reuse os.path.join() (directly for
source_from_cache(), indirectly through easy algorithmic copying in
cache_from_source()) do we want to keep the "special" semantics, or
can I change it to match what ntpath would do when there can be more
than one path separator on an OS (i.e. not do anything special)?
Is there an issue here with importing from zip files, which use /
separator, versus importing from the file system, which on Windows can
use either / or \ ? I don't know if imp.cache_from_source cares or is
aware, but it is the only thing I can think of that might have an impact
on such semantics. (Well, the other is command line usage, but I don't
think you are dealing with command lines at that point.)
_______________________________________________
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
