PyWart: Module access syntax

[Rick Johnson]

On Friday, 1-11-2013 10:02:34 AM, Steven D'Aprano wrote:
> Solution to what? You can only have a solution once you have identified a 
> problem. You have not identified a problem. In any case, your suggestion 
> is *not* obvious.

The problem is that by using the dot ubiquitously we are obfuscating the path to an identifier. 

> >  import lib:gui:tkinter:dialogs.SimpleDialog as Blah
> 
> Which names are packages, modules, classes, methods, functions, or other 
> objects?
> 
> Why do you have lib:gui but dialogs.SimpleDialog? Is the rule "classes 
> should always be preceded by a dot?"

No the rules are: 
    * "Colon" must be used to access a "module" (or a package).
    * "Dot" must be used to access a "module member".
    
In the line "lib:gui:tkinter:dialogs.SimpleDialog", "lib", "gui", "tkinter", and "dialogs" are all packages (or modules: same thing as far as paths are concerned). "SimpleDialog" however is a class, who's identifier is a member of the module "lib:gui:tkinter:dialogs". 

> Following this import:
> 
> import lib:gui
> 
> how do I access attributes of that module? 
> 
> x = lib:gui:function() perhaps? Now I have to remember which attribute 
> access uses dot operator and which uses colon operator.

It's simple: MODULES&PACKAGES use colon, MODULE MEMBERS use dot. How many times must i explain these simple rules?

If you don't know which names are modules and which names are members then how could a programmer possibly use the API in an intelligent way Steven? This syntax does not help the programmer much. Well, it can be beneficial to the programmer if he gets a *PathError* because he foolishly tried to instance a module named "simpledialog" when he actually meant to instance the object "simpledialog.SimpleDialog". (notice i did not use the word class!)

Traceback (most recent call last):
  File "<blah>", line 1, in <module>
    dlg = lib:gui:tkinter:dialogs.simpledialog()
PathError: name 'simpledialog' is a module NOT a object!

But that is not the reason for this syntax Steven, it is just a pleasant side effect.

> Does this mean there needs to four new be special methods:
> 
> __getcolonattribute__
> __getcolonattr__
> __setcolonattr__ 
> __delcolonattr__ 

Gawd no. getattr, setattr, and delattr will remain unchanged. The only change is how a /path/ to an identifier is "formed".

> to match the regular dot operator methods
> 
> __getattribute__
> __getattr__ 
> __setattr__ 
> __delattr__ 
> 
> ? Or do you think that the Python compiler should special-case attribute 
> access from modules?

There is no "special casing" needed. Python could happily replace all colons in a path with dots and interpret the path internally just as it does today.

> Before thinking about the syntax, you need to think about the behaviour, 
> identify what actual problem you hope to solve, and how you hope to solve 
> it. Not just throw random syntax around and hope that it's "obvious".

*The problem:*
... is readability. The current dot syntax used ubiquitously in paths is not conveying the proper information to the reader, and in-fact obfuscating the code.

*Method to solve the problem:*
... by introducing a new syntax that requires all module access to use the colon and all module members to use the dot.

*The syntax:*
... is perfect. Of course we could argue over /which/ char to use, but no matter which char prevails, we are gaining explicitness at zero overhead to the programmer because we are replacing one single char(dot) for one single  char(colon). The maintainer is the real winner. This is a win-win all around.