Per RFC 1738 section 3.10: "A file URL takes the form: 
file://<host>/<path> ... As a special case, <host> can 
be the string "localhost" or the empty string; this is 
interpreted as `the machine from which the URL is being 
interpreted".

In other words, regardless of what DNS or NetBIOS say 
about "localhost", it is always the local machine.

Therefore, functions like urllib.url2pathname() and 
urllib.urlopen() and anything else that takes a URL 
argument should treat '///path/to/file' 
and '//localhost/path/to/file' identically, 
returning '/path/to/file' on Unix or '\path\to\file' on 
Windows, for example.

(note separate bug report filed for url2pathname() 
mishandling '///path/to/file' on Windows)

Logged In: YES 
user_id=548370

Should be closed; duplicate of bug #607789, now closed.

Logged In: YES 
user_id=371366

I didn't realize it was a duplicate. I'm OK with the resolution 
of #607789. So I am changing this one to Closed / Duplicate.

In hindsight, I feel there are so many little conformance bugs 
in urllib that are so entrenched, there's no reason to assume 
that true RFC conformance was ever the intent or that it is a 
reasonable goal. Much code out there, within core Python libs 
and without, is written to match urllib's current behavior, or 
vice-versa.

If anyone's curious, I have implemented some urllib 
workarounds and RFC 2396bis (new version of RFC 2396, the 
URI spec) compliant features in 4Suite's Ft.Lib.Uri module, 
which can be reviewed at http://cvs.4suite.org/cgi-
bin/viewcvs.cgi/~checkout~/4Suite/Ft/Lib/Uri.py?
rev=HEAD&content-type=text/plain  ... it's always a work in 
progress, but is getting close to having a fork stuck in it for 
our upcoming 1.0 release.