I think the distinction you are trying to make here is based upon the
submodule's actual source location on the disk. If you have a package
folder A which contains a file B.py, then you would access that as
A:B, correct? If on the other hand you have a module A.py or package
A/__init__.py that loads a module from some other location and then
stores it in the A module with the name "B", then that would be "A.B",
correct?
Yes! The colon accesses package space (the "top-level namespace" if you will). The dot accesses members.
If I have that right, then the problem with this is that it breaks the
virtualization and encapsulation of Python's package structure. When
I import os.path, I don't have to know or care how the submodule
relationship is implemented, whether it's a simple module in a package
or something more complicated. All I need to know is that path is a
submodule of os.
Well one the main problem with packages is that we have no rules for defining them. I think of packages as namespaces. And as such they should have public members, private members, and shared members. The author of ANY package should place the /public members/ into the __init__ file *via import* foraccess by the user. The user should NEVER access package sub-modules directly!
What you're asking for is that I have to type either
"os.path" or "os
ath" depending on an implementation detail of the
module structure, and if that implementation detail ever changes, then
my code breaks.
You keep using os.path as an example. path should be it's OWN module livingin some package, and NOT a member of os. So you would import them separately. But if insist on keeping "path" in "os", fine. Even IF os where a package, the syntax would still be the same because there is only one level of package ("os") before you get to the member "path". Do you understand?
os.path.whatever
However, if "os" lived in a package named "lib" you would access via:
lib
s.path
See, the colon designates package namespace.
But these modules are bad examples because they do not require deep nestingof packages. GUI libraries however are a great example. That is why i posted the hypothetical path:
lib:gui:tk:dialogs.SimpleDialog
Here are few more to get a feel:
lib:gui:tk:dialogs.MessageBox
lib:gui:tk:dialogs.FileDlg
lib:gui:tk.constants
lib:gui:tk:widgets:Button
lib:gui:tk:widgets:XXX
If we build consistent packages and use a consistent syntax to access them,our code will be self documenting. However, I don't think the Python devs take the subject of packages very seriously.
For example, look at Tkinter in Py3000, we still have a single monolithic "tkinter" module with every possible widget class stuffed into it, along with ABCs, and variables classes, and outdated functions, and the kitchen sink! All they did was to move and rename the dialog and font classes and then patted themselves on the back.
This is NOT how you structure a package! We need to use a structured package approach to tame this wild beast called Tkinter.
Look, maybe nobody has the time to deal with this module, so if you need some help, then feel free to ask for my assistance. All Guido has to do is send me a private email and say:
""" Hello Rick! Your ideas for packaging of Tkinter are interesting, and i would like for you to send a patch over to {0} for immediate consideration.Thanks GvR """.format(destination)
But if he cannot even care enough about Python to send a single paragraph email, or he's holding a grudge because i am critical of "some" parts of thelanguage, well then, don't be expecting any help from me! I would not bother to criticize if i did not think Python was the best base for which to build a great language.
Nobody can build a perfect language, Guido included. You give it you best shot and then you tweak and tinker as new unforeseen problems arise. Sometimes you have no choice but to break backwards compatibility. These are all necessary stepping stones in a languages evolution. This snake needs to shedan old skin so the new skin can grow.
