[Python-Dev] path joining on Windows and imp.cache_from_source()

[Glenn Linderman]

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.)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-dev/attachments/20120421/7f9ea2e4/attachment-0001.html>