On Sun, 22 Apr 2012 07:45:27 +0200
"Martin v. Löwis" wrote:
>
> This goes back to
>
> http://codereview.appspot.com/842043/diff/1/3#newcode787
>
> where Antoine points out that the code needs to look for altsep.
>
> He then suggests "keep the right-most of both". I don't think he
> literally m
On Sun, Apr 22, 2012 at 01:45, "Martin v. Löwis" wrote:
> > 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 w
On Sun, Apr 22, 2012 at 01:44, Glenn Linderman wrote:
> 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 u
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 pat
> 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
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_
