Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > Python > PyWart: Module access syntax

Reply
Thread Tools

PyWart: Module access syntax

 
 
Rick Johnson
Guest
Posts: n/a
 
      01-15-2013
On Monday, January 14, 2013 11:34:56 AM UTC-6, Steven D'Aprano wrote:

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


But you forgot the rule about accessing module members with the dot

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


I will admit i may have confused a few of you (and myself) since i overused the word "module" when i really meant "package".

pkg1kg2kgN.member1.member2.memberN
 
Reply With Quote
 
 
 
 
Rick Johnson
Guest
Posts: n/a
 
      01-15-2013
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 will). The dot accesses members.

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


Well one the main problem with packages is that we have no rules for defining them. I think of packages as namespaces. And as such they should have public members, private members, and shared members. The author of ANY package should place the /public members/ into the __init__ file *via import* foraccess by the user. The user should NEVER access package sub-modules directly!

> What you're asking for is that I have to type either
> "os.path" or "osath" 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 livingin some package, and NOT a member of os. So you would import them separately. But if insist on keeping "path" in "os", fine. Even IF os where a package, the syntax would still be the same because there is only one level of package ("os") before you get to the member "path". Do you understand?

os.path.whatever

However, if "os" lived in a package named "lib" you would access via:

libs.path

See, the colon designates package namespace.

But these modules are bad examples because they do not require deep nestingof packages. GUI libraries however are a great example. That is why i posted 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

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.

For example, look at Tkinter in Py3000, we still have a single monolithic "tkinter" module with every possible widget class stuffed into it, along with 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 package approach to tame this wild beast called Tkinter.

Look, maybe nobody has the time to deal with this module, so if you need some help, then feel free to ask for my assistance. All Guido has to do is send 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 email, or he's holding a grudge because i am critical of "some" parts of thelanguage, well then, don't be expecting any help from me! I would not bother to criticize if i did not think Python was the best base for which to build a great language.

Nobody can build a perfect language, Guido included. You give it you best shot and then you tweak and tinker as new unforeseen problems arise. Sometimes you have no choice but to break backwards compatibility. These are all necessary stepping stones in a languages evolution. This snake needs to shedan old skin so the new skin can grow.

 
Reply With Quote
 
 
 
 
Rick Johnson
Guest
Posts: n/a
 
      01-15-2013
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 will). The dot accesses members.

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


Well one the main problem with packages is that we have no rules for defining them. I think of packages as namespaces. And as such they should have public members, private members, and shared members. The author of ANY package should place the /public members/ into the __init__ file *via import* foraccess by the user. The user should NEVER access package sub-modules directly!

> What you're asking for is that I have to type either
> "os.path" or "osath" 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 livingin some package, and NOT a member of os. So you would import them separately. But if insist on keeping "path" in "os", fine. Even IF os where a package, the syntax would still be the same because there is only one level of package ("os") before you get to the member "path". Do you understand?

os.path.whatever

However, if "os" lived in a package named "lib" you would access via:

libs.path

See, the colon designates package namespace.

But these modules are bad examples because they do not require deep nestingof packages. GUI libraries however are a great example. That is why i posted 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

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.

For example, look at Tkinter in Py3000, we still have a single monolithic "tkinter" module with every possible widget class stuffed into it, along with 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 package approach to tame this wild beast called Tkinter.

Look, maybe nobody has the time to deal with this module, so if you need some help, then feel free to ask for my assistance. All Guido has to do is send 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 email, or he's holding a grudge because i am critical of "some" parts of thelanguage, well then, don't be expecting any help from me! I would not bother to criticize if i did not think Python was the best base for which to build a great language.

Nobody can build a perfect language, Guido included. You give it you best shot and then you tweak and tinker as new unforeseen problems arise. Sometimes you have no choice but to break backwards compatibility. These are all necessary stepping stones in a languages evolution. This snake needs to shedan old skin so the new skin can grow.

 
Reply With Quote
 
Chris Angelico
Guest
Posts: n/a
 
      01-15-2013
On Tue, Jan 15, 2013 at 6:49 PM, Rick Johnson
<(E-Mail Removed)> wrote:
> Look, maybe nobody has the time to deal with this module, so if you need some help, then feel free to ask for my assistance. All Guido has to do is send 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)


Python's open source. Grab the source, do it, and post! Consider
yourself preemptively invited.

I'm not kidding. You don't need to wait for Guido's invitation to do
something. Just get in there, do something, and (preferably) show an
upgrade path from "current status" to "proposed status" - which might
involve a translation script similar to 2to3 - and people WILL take
notice.

ChrisA
 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
Re: F2PY: Access Fortran module data from multiple python module Gabriel Genellina Python 0 11-21-2008 04:22 AM
help - Module needs access to another module abcd Python 4 03-20-2007 10:10 PM
Re: module docstring, documentation,anything? please note is the module type/object NOT some module Maric Michaud Python 0 06-24-2006 12:42 PM
Syntax highligth with textile: Syntax+RedCloth ? gabriele renzi Ruby 2 12-31-2005 02:44 AM
Using JYTHON inside ANT : access os module -> "ImportError: no module named javaos" eric_bellard Python 1 10-07-2004 05:41 AM



Advertisments