When executing a script from a UNC path, e.g. //myhost/exports/a.py, 
r"\\myhost\exports" gets prepended to sys.path.  But it doesn't work.  
This means that in a.py, "import b" will fail even though b.py is 
present in the same directory.

The workaround is to manually prepend a backslass to the UNC path in 
sys.path.

Note the related defect: http://bugs.python.org/issue954115
This intdoruces two functions for testing UNC paths, but it appears 
that these functions are nowhere used!

Correction: The workaround is to _append_ a backslash.

Kristjan, you suggested this issue for consideration for 2.5.3.

Is there an actual patch to apply?

If not, the issue should get forwarded to 2.7 (and then to 2.8, and so
on, until somebody actually comes up with a patch).

No, not really.
Again, I refer to defect 954115 by glchapman.  And note that those 
functions added there are actually not used.
I was hoping that there was someone here more familiar with importing 
on PC.
I'll go and see if the old defect still applies and if there is perhaps 
a more general fix to be made.

Ok, un-targetting this from 2.5.3 then. 

Usage of IsUNCRoot disappeared as part of r42230, which dropped usage of
the C library for stat implementations. This only affects os.stat,
though, so I don't see the relation to this issue.

For the record: What *exactly* is the problem? I.e. specifically, what
do you do, what happens, what do you expect to happen instead?

I think this is stat(2) problem on windows. Please try following test
program.

#include <stdio.h>
#include <sys/stat.h>
#include <windows.h>

void test(const char *path)
{
    struct stat st;

    printf("%s %d %d\n", path, stat(path, &st), GetFileAttributes(path));
}

int main()
{
    test("e:\\shared");
    test("e:\\shared\\"); /* issue1293 */
    test("e:\\shared\\a.py");
    test("\\\\whiterab-c2znlh\\shared"); /* this issue */
    test("\\\\whiterab-c2znlh\\shared\\");
    test("\\\\whiterab-c2znlh\\shared\\a.py");
}

And this is result.

e:\shared 0 16
e:\shared\ -1 16
e:\shared\a.py 0 32
\\whiterab-c2znlh\shared -1 16
\\whiterab-c2znlh\shared\ 0 16
\\whiterab-c2znlh\shared\a.py 0 32

As discussed in issue1293, stat(2) fails for the normal folder path with
trailing slash, and also fails for the UNC folder path without trailing
slash. I'm using VC6, but same behavior on VC9?

trunk/Python/import.c(3160) and trunk/Modules/zipimport.c(99) is using
stat(2).

I'll create patch to prove my observation. :-)

Ah, of cource, please change path to fit you environment. > test prog

zipimport.c seems fine, because stat(2) succeeds for UNC file. It fails
for UNC folder. (zip file is absolutely file)

Already fix for issue1293 was in, so maybe I should create the patch for
that direction but... anyway this issue seems to be fixed by my patch. I
also confirmed the test script in http://bugs.python.org/msg56523 works.

Just humble thought...
If we can replace stat(2) + S_ISDIR/S_ISREG check with
GetFileAttributesEx, maybe we are safe for this kind of problem, and can
solve issue3099 same time? :-)

Okay, I've tested the patch and made some beauty fixes.
Can we have this in, please?

Checked in as revision: 68457

This fix needs to be ported to the py3k branch. Can somebody please do it?

Merged in r68873(py3k).

The path variable should be PyMem_Free'd (in both trunk and py3k)
(also, I don't see any specific test - is there any?)

added the mem release in r68882.
I'll try to add test cases too.

Added tests for UNC path imports in r68883 and r68884

>The path variable should be PyMem_Free'd

Sorry if I'm missing something, but is this really needed?
Other PyArg_ParseTuple(args, "s... doesn't seem to have
corresponding PyMem_Free.

static PyObject *
imp_new_module(PyObject *self, PyObject *args)
{
	char *name;
	if (!PyArg_ParseTuple(args, "s:new_module", &name))
		return NULL;
	return PyModule_New(name);
}

> Sorry if I'm missing something, but is this really needed?

Yes, the "es" converter allocates memory.

Ah, "es" is used in py3k, thanks. And sorry about my merge which had 
memory leak.