PyWart: Module access syntax

R

Rick Johnson

Python's module/package access uses dot notation.

mod1.mod2.mod3.modN

Like many warts of the language, this wart is not so apparent when first learning the language. The dot seems innocently sufficient, however, in truthit is woefully inadequate! Observe:

name1.name2.name3.name4.name5

Can you tell me which names are modules, which are classes, and which are methods/functions? Wait, i know the argument you'll use:

"""I can decipher from spelling! Modules use all lowercase, classes use initial uppercase, and methods use words_sep_by_underscore. I'm so smart!"""

Indeed. But that's only *_IF_* everybody used the same style guide. And as we know many people don't follow the style guide (not to mention the style guide has issues!) And since style is NOT enforced, we suffer the unintuitive syntax nightmare! The solution is obvious by using proper syntax.

import lib:gui:tkinter:dialogs.SimpleDialog as Blah

You /could/ use two colons:

import lib::gui::tkinter::dialogs.SimpleDialog as Blah

....and i think this syntax does help to separate the identifiers more clearly, but since these imports can be quite long, i prefer the single colon myself.
 
S

Steven D'Aprano

Python's module/package access uses dot notation.

mod1.mod2.mod3.modN

Like many warts of the language, this wart is not so apparent when first
learning the language. The dot seems innocently sufficient, however, in
truth it is woefully inadequate! Observe:

name1.name2.name3.name4.name5

Can you tell me which names are modules, which are classes, and which
are methods/functions? Wait, i know the argument you'll use:

"""I can decipher from spelling! Modules use all lowercase, classes
use initial uppercase, and methods use words_sep_by_underscore. I'm so
smart!"""

Wrong. My answer is...

Who cares? Why do you care which names are modules, classes, etc? This is
Python, and duck-typing rules!

Today I have:

x = mylib.stuff.spam().parrot.speak()

where:

- mylib is a module
- stuff is a separate module imported into mylib
- spam is a class
- parrot a data attribute
- and speak a method.

But then tomorrow I re-factor the code and turn:

- mylib into a package
- stuff into a module of the package
- spam into a factory function
- parrot into a property
- and speak into a dynamically generated static method created using
__getattr__.

How do I write this new code? Exactly the same as the old code -- no
changes are required!

x = mylib.stuff.spam().parrot.speak()

*It doesn't matter* what kind of entity each of the dotted names
represent, so long as they have the expected interface.

The solution is obvious by using proper syntax.

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

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.

Does this mean there needs to four new be special methods:

__getcolonattribute__
__getcolonattr__
__setcolonattr__
__delcolonattr__

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?

You /could/ use two colons:

import lib::gui::tkinter::dialogs.SimpleDialog as Blah

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

Rick Johnson

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.
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 tothe 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 singlechar(colon). The maintainer is the real winner. This is a win-win all around.
 
C

Chris Angelico

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

Please explain how this is a problem. As Steven said, there is NO
useful difference. I don't *care* whether it's a package, a module, or
whatever. Module with class with static member? Fine. Package with
module with class? Also fine. Imported special object that uses dunder
methods to simulate either of the above? What's it matter to me, as
long as I get my final result!

Syntactic salt is seldom helpful.

ChrisA
 
R

Rick Johnson

Please explain how this is a problem.


What is this importing?

"import lib.gui.simpledialog"

....is that the "simpledialog module" or "SimpleDialog object"? Since namingconventions are not ENFORCED, we can NEVER be sure if an identifier is a object or module. And since object definitions (aka: classes) are often placed into a module with the same name, how are we to know? Why should we be forced to open source files to find out a small detail that proper syntax can easily provide?

This is a matter of READABILITY, Christopher. It's one or the other (or thestatus quo):

1. Enforce naming conventions.
2. Enforce path syntax.
3. Continue to obfuscate code.

The choice is yours.
 
R

Rick Johnson

Please explain how this is a problem.


What is this importing?

"import lib.gui.simpledialog"

....is that the "simpledialog module" or "SimpleDialog object"? Since namingconventions are not ENFORCED, we can NEVER be sure if an identifier is a object or module. And since object definitions (aka: classes) are often placed into a module with the same name, how are we to know? Why should we be forced to open source files to find out a small detail that proper syntax can easily provide?

This is a matter of READABILITY, Christopher. It's one or the other (or thestatus quo):

1. Enforce naming conventions.
2. Enforce path syntax.
3. Continue to obfuscate code.

The choice is yours.
 
C

Chris Angelico

This is a matter of READABILITY, Christopher. It's one or the other (or the status quo):

1. Enforce naming conventions.
2. Enforce path syntax.
3. Continue to duck type, like Python is good at.

The choice is yours.

FTFY.

ChrisA
 
S

Steven D'Aprano

No the rules are:
* "Colon" must be used to access a "module" (or a package).
* "Dot" must be used to access a "module member".

So what do you do for, say, os.path? According to the first rule, you
must write it as os:path because path is a module; according to the
second rule, you must write it as os.path because path is a member of os.
So which rule wins?

If I do this:

import math
import string
math.string = string


is that legal, or do I have to write "math:string = string"?



Suppose I do this:


import random
if random.random() < 0.5:
math.string = "NOBODY expects the Spanish Inquisition!"
else:
math.string = string # assuming this actually is allowed


How do I access the string member?

try:
print math.string # only works if string is a str object
except SomeException:
print math:string # only works if string is a module object


That would suck *and* blow at the same time. I don't need to know the
type of any other member object in order to look it up, why should I have
to care whether it is a module?

Now, suppose I then do this:

class Blob: pass

blob = Blob()
blob.math = math # or should that be blob:math ?

Now do I have to write this?

blob.math:string.letters

(assuming that math:string is a module, not a str object).


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

At the time I asked the question, you hadn't explained it *at all*.


[...]
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!)

"Instance" is a noun. The verb you are looking for is "instantiate".

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!

Of course it is an object. *Everything* in Python is an object. Modules
are objects. Strings are objects. Types and classes are objects. None is
an object. Metaclasses are objects. Properties are objects. Exceptions
are objects. Have I made it clear yet?


[...]
*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.

So you say. I think you are caring too much about the type of members and
not enough about what interface they provide. Why do you care if I grab
module.my_singleton_object and replace my_singleton_object with a module?

Modules are singletons in Python, in the sense that every[1] time you
import a module you get the same object. Using modules as members for
their singleton properties, not for their importability, is a common
technique. With your proposal, I need to know whether a member is a
module, or any other type, before I can access it. That is a really
shitty design. Instead of having one syntax for *all* attribute access,
now you have two, and we have to care whether a member is a module or
not, which we never did before.

Worse, you couple the syntax to implementation: if I use a module as a
singleton, I need to use one syntax; if I use a custom type as a
singleton, I have to use different syntax. Whichever choice I make
*today*, if the implementation changes, the required syntax changes and
my code will break.




[1] Well, almost. There are ways to accidentally or deliberately confuse
the import machinery.
 
S

Steven D'Aprano

What is this importing?

"import lib.gui.simpledialog"

...is that the "simpledialog module" or "SimpleDialog object"?

It has to be the first, because:

- you can't import members of modules directly using dot syntax

("import math.cos" will fail)

- and it can't be SimpleDialog, because Python is case-sensitive and you
wrote simpledialog.


But ignoring the import, and just looking at the dotted name:

lib.gui.simpledialog

who cares what simpledialog happens to be? So long as you know the
expected interface (say, "it's a callable object that takes three
arguments"), you can use it the same way whether it is a function, a
method, a class or something else. The implementation could change, and
you need not care.

If you actually do care what the type of simpledialog is, you can find
out easily:

type(lib.gui.simpledialog)
 
I

Ian Kelly

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 manytimes 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 beneficialto 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.
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?
 
A

alex23

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

Your initial argument is that with import's current dot notation, it's
not obvious which is a module or not without accessing the
documentation.

You then say it's necessary to know which is which in order to use
your suggested dot/colon notation.

So what are you trying to achieve here? Your 'solution' requires
someone to look up the documentation and know what is what, whereas
the current approach _doesn't_. Anything can be imported into the
current scope, and interrogated there without recourse to
documentation. Your approach places onerous requirements on everyone
just to satisfy some arbitrary rule-set you've pulled out of your
rectum.

It's not up to _my_ code to identify how _supporting libraries_ are
structured. It just wants to import and use them. Which is, you know,
the pragmatic, get-things-done-over-endless-wanking-on-the-mailing-
list approach that Python is famous for.

You're trolling again, plain & simple.
 
N

Nicholas Cole

Python's module/package access uses dot notation.

mod1.mod2.mod3.modN

Like many warts of the language, this wart is not so apparent when first
learning the language. The dot seems innocently sufficient, however, in
truth it is woefully inadequate! Observe:

name1.name2.name3.name4.name5
I find it reassuring to have these kinds of questions on the list, because
they actually remind me how brilliantly designed Python is.

As the user of a module I shouldn't care about the internal arrangement of
objects and files. I don't care. More than that, as the writer of a
module I should be free to refactor the internals of a module without
breaking existing code.

There is absolutely nothing wrong at all with the syntax. In fact, it's
fantastic.

N.
 
8

88888 Dihedral

Chris Angelicoæ–¼ 2013å¹´1月12日星期六UTC+8下åˆ12時40分36秒寫é“:
Please explain how this is a problem. As Steven said, there is NO

useful difference. I don't *care* whether it's a package, a module, or

whatever. Module with class with static member? Fine. Package with

module with class? Also fine. Imported special object that uses dunder

methods to simulate either of the above? What's it matter to me, as

long as I get my final result!



Syntactic salt is seldom helpful.



ChrisA
This is somewhat like the following problem.

Do we have to argue with people about the tastes
of dishes in different restaurants ?

Of course, I do because I love to enjoy fine dishes.
 
8

88888 Dihedral

Chris Angelicoæ–¼ 2013å¹´1月12日星期六UTC+8下åˆ12時40分36秒寫é“:
Please explain how this is a problem. As Steven said, there is NO

useful difference. I don't *care* whether it's a package, a module, or

whatever. Module with class with static member? Fine. Package with

module with class? Also fine. Imported special object that uses dunder

methods to simulate either of the above? What's it matter to me, as

long as I get my final result!



Syntactic salt is seldom helpful.



ChrisA
This is somewhat like the following problem.

Do we have to argue with people about the tastes
of dishes in different restaurants ?

Of course, I do because I love to enjoy fine dishes.
 
R

Rick Johnson

So what do you do for, say, os.path? According to the first rule, you
must write it as os:path because path is a module; according to the
second rule, you must write it as os.path because path is a member of os.
So which rule wins?

Since "path" is an identifier in the module "os" that points to a system specific module (which is loaded at run-time), you would access os.path just as you do today; using the dot. No changes here. Next!
If I do this:

import math
import string
math.string = string

is that legal, or do I have to write "math:string = string"?

No. You are assigning the module "string" to a member variable of the module "math" so you use the dot. No changes here. Next!
Suppose I do this:
*rolls-eyes*

import random
if random.random() < 0.5:
math.string = "NOBODY expects the Spanish Inquisition!"
else:
math.string = string # assuming this actually is allowed

....first allow me to remove all the cruft so you can ask this next iteration of the _same_ hypothetical question succinctly.

if some_condition:
math.string = ""
else
math.string = string
How do I access the string member?

You access the member variable named "string" (that points to the "string module") as you would ANY _member_, using the dot. Next!
try:
print math.string # only works if string is a str object
except SomeException:
print math:string # only works if string is a module object

EARTH TO STEVEN: You are sadly misunderstanding my suggested syntax and frankly making a complete fool of yourself. I cannot allow this to go on any longer.
That would suck *and* blow at the same time.

Yes it would, but that's only _IF_ my suggested syntax works in the backwards way you suggest. Lucky for us, i'm designing this feature.
I don't need to know the
type of any other member object in order to look it up, why should I have
to care whether it is a module?

I said it before and i'll say it again: If you don't know if your calls areaccessing module space or object space (be it instanced object or static object), then you are sadly informed and shooting from the hip -- you're going to shoot your toes off! But that is not the worst part, no. The worst part is that by using only the dot, your code is superfluously obfuscated. That is a crime to me. A crime punishable by the syntax error. I condemn you to tortuous syntax errors until you change your rebellious ways.
Now, suppose I then do this:

class Blob: pass

blob = Blob()
blob.math = math # or should that be blob:math ?

Oh lord.

Has anyone noticed that every one of these hypotheticals is presenting the very same question using different circumstances. Do you think 1+1 will sometimes equal 2 Steven?

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.

Observe:

In module "lib:foo":
import string
import math
import math as _math
from math import ceil
#
string.math = math
string.math.var="var"


In __main__ (test 1):
import lib:foo
import lib:foo as foo
# Test 1
print lib:foo.string.math.var -> "var"
# Test 2
print foo.string.math.var -> "var"
# Test 3
foo.string.math.ceil(.1) -> 1.0
# Test 4:
foo.ceil(.1) -> 1.0
[...]
Traceback (most recent call last):
File "<blah>", line 1, in <module>
dlg = lib:gui:tkinter:dialogs.simpledialog()


Of course it is an object. *Everything* in Python is an object.

And i agree! ("it" being "modules" in this case)
Modules
are objects. Strings are objects. Types and classes are objects.

Wait, "classes" are NOT objects. Classes are structured code that DEFINE anobject. You see, this is exactly why we need to stop using the word "class" to describe an "object definition". Your ability to grasp _what_ an object definition *IS* is due to poor terminology.
None is
an object. Metaclasses are objects. Properties are objects. Exceptions
are objects. Have I made it clear yet?

Yes, but your point is invalid. I was comparing a module to an object. And even though EVERYTHING in Python is technically an object, you should have inferred the meaning of my comparison, but alas, you cannot even infer my syntax!
So you say. I think you are caring too much about the type of members and
not enough about what interface they provide. Why do you care if I grab
module.my_singleton_object and replace my_singleton_object with a module?

Because modules and objects are not the same and someone who is reading thesource 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.

Look, we cannot provide /every/ possible detail about an object via syntax alone, HOWEVER, here we have a golden opportunity to provide one more pieceof that puzzle without any negative trade-offs. Oh yes, *rolls-eyes*, the programmer will need to be sure he places a colon between modules. Which means a programmer will need to know which path members are modules and whichare objects... But are you actually telling me that you're unable to remember which objects you are accessing are modules and which are members? And if you cannot, you /could/ resolve the conflict much easier yourself than areader can resolve the conflict -- Why? because you are closer to the codestructure. And why are you closer to the code structure? BECAUSE YOU WROTEIT!
Modules are singletons in Python, in the sense that every[1] time you
import a module you get the same object. Using modules as members for
their singleton properties, not for their importability, is a common
technique. With your proposal, I need to know whether a member is a
module, or any other type, before I can access it.

WRONG! What you need to do is to read my proposal again and try to comprehend it before going off on these nonsensical tirades.
That is a really
shitty design. Instead of having one syntax for *all* attribute access,
now you have two, and we have to care whether a member is a module or
not, which we never did before.

Are you serious? You are pissing and moaning about keeping up with TWO types and any /real/ programmer has to corral many *many* types in one program?

We not only have to care if a member is a module or not Steven, we have to care whether a member is a float, or an integer, or a string, or a tuple, or a complex, or an iterator, or a range, or a list, or a set, or a frozenset, or a dict, or a ordereddict or a function, or an object (as in: "user defined object") or blah, blah, blah.

Your argument is nothing more than BS. You thought you could fool me with sleight of hand. Nice try, but you lose. Better luck next time.

py> currentTroll.vanquish()
py> trollist.next()
 
S

Steven D'Aprano

So what do you do for, say, os.path? According to the first rule, you
must write it as os:path because path is a module; according to the
second rule, you must write it as os.path because path is a member of
os. So which rule wins?

Since "path" is an identifier in the module "os" that points to a system
specific module (which is loaded at run-time), you would access os.path
just as you do today; using the dot. No changes here. Next!

Here you say that os.path will not change. But later in your post, you
say:

the programmer will need to be sure he places a colon
between modules. Which means a programmer will need to know which path
members are modules and which are objects

Since both os and path are modules, you here say that they need a colon
between them. This contradicts the above when you say the syntax for
os.path won't change.

If even you don't understand your own proposal, how do you expect anyone
else to understand it?

Perhaps you should start by explaining, unambiguously and IN FULL, under
what circumstances the programmer will need to use your : syntax.

To start:

os.path or os:path

json.scanner or json:scanner


I said it before and i'll say it again: If you don't know if your calls
are accessing module space or object space (be it instanced object or
static object), then you are sadly informed

"Sadly informed"? Dr Freud called, he wants his slip back.

Modules are objects, and there is no difference between module space and
object space, except that Python provides a convenience syntax for
members of the current module. Modules are instances of a class, just
like ints, strings, lists, and everything else.


py> from types import ModuleType
py> type(ModuleType) is type(int)
True

py> hasattr(os, '__dict__')
True


[...]
Wait, "classes" are NOT objects.

They certainly are. Classes are created at runtime, they have a type --
the class of a class is the metaclass. You can even customize class
behaviour with metaclass programming.

Perhaps you are thinking about some other language, like Java, which
fails to have first-class classes (pun intended).
 
I

Ian Kelly

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

Ian Kelly

What's more, if the purpose of the syntax is to distinguish modules
from non-modules, then the syntax "os.path" (which you have stated
would not change) would be misleading, because the "path" part is in
fact a module. Your proposed syntax fails to even achieve its stated
goal.
 
D

D'Arcy J.M. Cain

On Sun, Jan 13, 2013 at 10:22 PM, Rick Johnson

If you want us to understand the syntax, then you need to define

If you are going to feed the trolls can I please ask that you Cc them
or send to them and Cc the list? That way those of us who filter out the
trolls can filter out the responses to them as well.

Thanks for understanding.
 
I

Ian Kelly

If you are going to feed the trolls can I please ask that you Cc them
or send to them and Cc the list? That way those of us who filter out the
trolls can filter out the responses to them as well.

Sorry about that. I actually have him filtered out too, but then I
see other people's responses and I get sucked in.
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Members online

No members online now.

Forum statistics

Threads
473,744
Messages
2,569,483
Members
44,902
Latest member
Elena68X5

Latest Threads

Top