PyWart: Module access syntax

[Ian Kelly]

On Fri, Jan 11, 2013 at 9:34 PM, Rick Johnson
<rantingrickjohnson at gmail.com> wrote:
> No the rules are:
>     * "Colon" must be used to access a "module" (or a package).
>     * "Dot" must be used to access a "module member".

What about module a that does not natively contain module b, but
imports it as a member like so?

a.py:
import b

Must this be accessed as a:b or a.b?

What about a module that is referenced by some other object that is
not a module?  Should it be "my_object.pickle_module" or
"my_object:pickle_module"?

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

Since you didn't actually explain them at all in your initial post, I
would have to say that once is enough.

> 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?

You might start by reading the documentation.

> 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!)

The problem here is bad naming on the part of the library designer,
not bad syntax.  Why is SimpleDialog confusingly contained in a module
also named simpledialog?  This is not Java; there is no absurd
requirement of one class per file.  A clearer path to SimpleDialog
would just be "lib.gui.tkinter.dialogs.SimpleDialog".

> 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!

See, here is the thing that seems to be eluding you.  In Python,
modules *are* objects.  You can bind names to them, just like any
other object.  You can add them to collections.  You can introspect
them.  Hell, you can even subclass ModuleType and create modules that
can be called or multiplied or iterated over or any crazy thing you
can think of.  Your : syntax is trying to treat modules as being
somehow special, but the fact is that they're *not* special, which is
why I think it's a bad idea.

>> 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".

Then how is ModuleType.__getattr__ supposed to know whether to raise a
"PathError" or not, after it determines whether the requested object
turned out to be a module or not?  It has no way of knowing whether it
was invoked by '.' or by ':' or by getattr or by direct invocation.

Or are you instead proposing a new bytecode "LOAD_COLON_ATTR" to
complement "LOAD_ATTR", and that every single occurrence of LOAD_ATTR
in every program would then have to check whether the loaded object
turned out to be a module and whether the object it was loaded from
also happened to be a module, all just to raise an exception in that
case instead of just giving the programmer what he wants?