PyWart: Module access syntax

Ian Kelly ian.g.kelly at gmail.com
Mon Jan 14 13:51:50 EST 2013


On Sun, Jan 13, 2013 at 10:22 PM, Rick Johnson
<rantingrickjohnson at gmail.com> wrote:
> You are missing the point of this syntax. The colon is to access MODULE NAMESPACE. The dot is to access MODULE MEMBERS. A module CAN BE another module's MEMBER.
>
> You are also unable to grasp this simple logical fact: Once you arrive at /any/ MODULE and you start accessing MEMBERS, you will *_ALWAYS_* find members from that point downwards.

If you want us to understand the syntax, then you need to define
precisely what you mean by these terms.  In what situation does a
module have a dotted/coloned path without being a member of another
module?  Any time you import a.b, the import mechanism finds and loads
module b and adds it *as a member* to module a.  It follows that a
module accessible by a module path is *always* a member of another
module.  By the above rule, then it would seem that the dot would
always be used, and the colon never.

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?

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

> Because modules and objects are not the same and someone who is reading the source code NEEDS to know which "path members" are /modules/ and which "path members" are /objects/.  And he needs to know that very important information WITHOUT opening source files to find out.

Why does anybody reading the source code need to know this?  We're
talking about simple namespaces here.  Nobody reading the source needs
to care whether those namespaces are implemented as modules or some
other type of object.  The only substantive difference between the two
is whether you can expect to be able to import them directly.  If you
need to know that, read the documentation.  If they're documented as
modules, then you can import them.  Otherwise, make no such
assumption, because even if it works now, that could change later.

If we're *not* talking about simple namespaces, then it should be very
obvious that they are not modules based upon the fact that the code
uses them in ways that modules are not normally used for.



More information about the Python-list mailing list