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

Brett Cannon brett at python.org
Sun Apr 22 08:00:11 CEST 2012

On Sun, Apr 22, 2012 at 01:44, Glenn Linderman <v+python at g.nevcal.com>wrote:

On 4/21/2012 8:53 PM, Brett Cannon wrote:

imp.cachefromsource() (and thus also imp.sourcefromcache()) has special semantics compared to how os.path.join() works. For instance, if you look at testimp 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.cachefromsource('\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.cachefromsource() 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 sourcefromcache(), indirectly through easy algorithmic copying in cachefromsource()) 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.cachefromsource 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.)

Right now zipimport doesn't even support pycache (I think). Besides, zipimport already does a string substitution of os.altsep with os.sep (see Modules/zipimport.c:90 amongst other places) so it also doesn't care in the end. -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://mail.python.org/pipermail/python-dev/attachments/20120422/c3c50694/attachment.html>

More information about the Python-Dev mailing list