On Sun, Jan 13, 2013 at 10:22 PM, Rick Johnson <rantingrickjohn...@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. -- http://mail.python.org/mailman/listinfo/python-list
