[Python-Dev] path joining on Windows and imp.cache_from_source() (original) (raw)
Brett Cannon brett at python.org
Sun Apr 22 05:53:57 CEST 2012
- Previous message: [Python-Dev] isolating import state during tests
- Next message: [Python-Dev] path joining on Windows and imp.cache_from_source()
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
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)? -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://mail.python.org/pipermail/python-dev/attachments/20120421/eab3949c/attachment.html>
- Previous message: [Python-Dev] isolating import state during tests
- Next message: [Python-Dev] path joining on Windows and imp.cache_from_source()
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]