RetroSearch Browse

Sun Apr 22 05:53:57 CEST 2012 · https://mail.python.org/pipermail/python-dev/2012-April/118961.html

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>

Home - News ( United States | United Kingdom | Italy | Germany ) - Football scores

Showing content from https://mail.python.org/pipermail/python-dev/2012-April/118961.html below:

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