On Monday, January 14, 2013 12:51:50 PM UTC-6, Ian wrote:
> 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* for access 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:path" 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 living in
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:os.path
See, the colon designates package namespace.
But these modules are bad examples because they do not require deep nesting of
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 the
language, 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 shed an old skin
so the new skin can grow.
--
http://mail.python.org/mailman/listinfo/python-list
