Maybe it is better to write all module filenames in /usr/local/lib/python3.9/urllib/

Solution for Maybe it is better to write all module filenames in /usr/local/lib/python3.9/urllib/
is Given Below:

By default ,you can’t import modules in urllib in python3.9.

Python 3.9.6 (default, Jul 14 2021, 09:15:03) 
[GCC 8.3.0] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> import urllib
>>> dir(urllib)
['__builtins__', '__cached__', '__doc__', '__file__', '__loader__', '__name__', '__package__', '__path__', '__spec__']

Let’s check which module is in urllib.

ls  /usr/local/lib/python3.9/urllib/  __pycache__
cat /usr/local/lib/python3.9/urllib/
#it contains blank line.

>>> import urllib
>>> web = urllib.request.urlopen('')
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
AttributeError: module 'urllib' has no attribute 'request'

The best practice is import urllib.request suggested on many tutorials online.
The is blank ,contains nothing ,by default.So one have to write import urllib.request to import it,now i add the below lines in the /usr/local/lib/python3.9/urllib/

from . import error
from . import parse
from . import request
from . import robotparser
from . import response

Then to open a webpage:

>>> import urllib
>>> web = urllib.request.urlopen('')
<bound method of <http.client.HTTPResponse object at 0x7f2654757430>>

Why the author doesn’t add the lines in /usr/local/lib/python3.9/urllib/

Looking at the Git history in the Python 3 source code, for cpython/Lib/urllib/, I found a single commit:

Make a new urllib package. It consists of code from urllib, urllib2, urlparse, and robotparser. The old modules have all been removed. The new package has five submodules: urllib.parse, urllib.request, urllib.response,
urllib.error, and urllib.robotparser. The urllib.request.urlopen() function uses the url opener from urllib2.

Then taking a look at the Python 2 source history, it appears that those four libraries all originally existed as flat files.

So my best guess is that, in combining a handful of related libraries together during the transition from Python 2 to 3, they decided that this submodule structure would be the easiest to understand and maintain. Forcing the issue by way of the file was likely meant to alleviate some confusion for end users with regards to the lineage of the methods: that is, which functions came originally from which Python 2 libraries. In essence, trading the marginal convenience of a top-level import for better modularity and clearer separation of concerns from the perspective of the users.