Path: csiph.com!newsfeed.hal-mli.net!feeder3.hal-mli.net!newsfeed.hal-mli.net!feeder2.hal-mli.net!newsfeed.xs4all.nl!newsfeed2.news.xs4all.nl!xs4all!newsgate.cistron.nl!newsgate.news.xs4all.nl!post.news.xs4all.nl!not-for-mail
Newsgroups: comp.lang.python
Date: Mon, 14 Jan 2013 23:49:25 -0800 (PST)
In-Reply-To: <mailman.512.1358189552.2939.python-list@python.org>
Complaints-To: groups-abuse@google.com
Injection-Info: glegroupsg2000goo.googlegroups.com; posting-host=70.196.104.160; posting-account=h3aEwQoAAACiuqX-oR3gvCVFm8lLHoWj
References: <8e9b2b0e-1c34-46cc-80c6-57fbb5fd756c@googlegroups.com> <50f03799$0$30003$c3e8da3$5496439d@news.astraweb.com> <9b64719e-1e06-47fa-a7e6-692a3dd360d0@googlegroups.com> <50f1066f$0$30003$c3e8da3$5496439d@news.astraweb.com> <af1ad595-4ee6-4b9f-86fb-845c025fb417@googlegroups.com> <mailman.512.1358189552.2939.python-list@python.org>
User-Agent: G2/1.0
MIME-Version: 1.0
Subject: Re: PyWart: Module access syntax
From: Rick Johnson <rantingrickjohnson@gmail.com>
To: comp.lang.python@googlegroups.com
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Cc: Python <python-list@python.org>
Precedence: list
Message-ID: <mailman.531.1358236175.2939.python-list@python.org>
Lines: 93
NNTP-Posting-Host: 2001:888:2000:d::a6
Xref: csiph.com comp.lang.python:36842

On Monday, January 14, 2013 12:51:50 PM UTC-6, Ian wrote:

> 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?

Yes! The colon accesses package space (the "top-level namespace" if you wil=
l). The dot accesses members.=20

> 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. =20

Well one the main problem with packages is that we have no rules for defini=
ng them. I think of packages as namespaces. And as such they should have pu=
blic members, private members, and shared members. The author of ANY packag=
e should place the /public members/ into the __init__ file *via import* for=
 access by the user. The user should NEVER access package sub-modules direc=
tly!

> 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.

You keep using os.path as an example. path should be it's OWN module living=
 in some package, and NOT a member of os. So you would import them separate=
ly. But if insist on keeping "path" in "os", fine. Even IF os where a packa=
ge, the syntax would still be the same because there is only one level of p=
ackage ("os") before you get to the member "path". Do you understand?

   os.path.whatever
  =20
However, if "os" lived in a package named "lib" you would access via:

  lib:os.path

See, the colon designates package namespace.

But these modules are bad examples because they do not require deep nesting=
 of packages. GUI libraries however are a great example. That is why i post=
ed the hypothetical path:

  lib:gui:tk:dialogs.SimpleDialog

Here are few more to get a feel:

  lib:gui:tk:dialogs.MessageBox
  lib:gui:tk:dialogs.FileDlg
  lib:gui:tk.constants
  lib:gui:tk:widgets:Button
  lib:gui:tk:widgets:XXX
 =20
If we build consistent packages and use a consistent syntax to access them,=
 our code will be self documenting. However, I don't think the Python devs =
take the subject of packages very seriously.=20

For example, look at Tkinter in Py3000, we still have a single monolithic "=
tkinter" module with every possible widget class stuffed into it, along wit=
h ABCs, and variables classes, and outdated functions, and the kitchen sink=
! All they did was to move and rename the dialog and font classes and then =
patted themselves on the back.

This is NOT how you structure a package!  We need to use a structured packa=
ge approach to tame this wild beast called Tkinter.=20

Look, maybe nobody has the time to deal with this module, so if you need so=
me help, then feel free to ask for my assistance. All Guido has to do is se=
nd me a private email and say:

""" Hello Rick! Your ideas for packaging of Tkinter are interesting, and i =
would like for you to send a patch over to {0} for immediate consideration.=
 Thanks GvR """.format(destination)

But if he cannot even care enough about Python to send a single paragraph e=
mail, or he's holding a grudge because i am critical of "some" parts of the=
 language, well then, don't be expecting any help from me! I would not both=
er to criticize if i did not think Python was the best base for which to bu=
ild a great language.

Nobody can build a perfect language, Guido included. You give it you best s=
hot and then you tweak and tinker as new unforeseen problems arise. Sometim=
es you have no choice but to break backwards compatibility. These are all n=
ecessary stepping stones in a languages evolution. This snake needs to shed=
 an old skin so the new skin can grow.