homepage

path 'g' in 'http:g' becomes '/g'.
 >>> urlsplit('http:g')
 SplitResult(scheme='http', netloc='', path='g', query='', fragment='')
 >>> urlunsplit(urlsplit('http:g'))
 'http:///g'
 >>> urlsplit('http:///g')
 SplitResult(scheme='http', netloc='', path='/g', query='', fragment='')
 >>> urljoin('http://a/b/c/d', 'http:g')
 'http://a/b/c/g'
 >>> urljoin('http://a/b/c/d', 'http:///g')
 'http://a/g'
The problematic part of the code is:
 def urlunsplit(components):
 [...]
 if netloc or (scheme and scheme in uses_netloc and url[:2] != '//'):
---> if url and url[:1] != '/': url = '/' + url
 url = '//' + (netloc or '') + url
Note also that urllib has decided on the interpretation of 'http:g' (in test).
 def test_RFC3986(self):
 [...]
 #self.checkJoin(RFC3986_BASE, 'http:g','http:g') # strict parser
 self.checkJoin(RFC3986_BASE, 'http:g','http://a/b/c/g') #relaxed parser

@op368 I don't think that this is a bug, [1] literally uses this exact example and shows the expected behaviour. 
[1] https://datatracker.ietf.org/doc/html/rfc3986#section-5.4.2 

hello, @jaswdr, but I can't understand what's wrong with my point.
What is 'the expected behaviour'?

@op368 as far as I can see, regarding of any miss interpretation, yes, the RFC has this section:
 "http:g" = "http:g" ; for strict parsers
 / "http://a/b/c/g" ; for backward compatibility
What I can understand is that for "http:g" it will be translated to "http:///g" because of backward compatibility, this seems to be an edge case for the parser, since the RFC text also mention that this should be avoided.

'http:///g' has absolute path '/g',
and as urljoin shows:
 >>> urljoin('http://a/b/c/d', 'http:///g')
 'http://a/g' # 'a' is netloc
So you are proposing third interpretation.
 "http:g" = "http:g" ; for strict parsers
 / "http://a/b/c/g" ; for backward compatibility
 / "http://a/g" ; (yours)

Not exactly, in the RFC example they use a/b/c for the path, but when using http:g there is no nested path, so it should be http:///g, no?

I tried hard (even read RFC1630),
but I think no.