PyWart: Module access syntax

[Rick Johnson]

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.