Velocity Reviews - Computer Hardware Reviews

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

Reply
Thread Tools

PyWart: Module access syntax

 
 
alex23
Guest
Posts: n/a
 
      01-12-2013
On 12 Jan, 14:34, Rick Johnson <(E-Mail Removed)> wrote:
> 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.
 
Reply With Quote
 
 
 
 
Nicholas Cole
Guest
Posts: n/a
 
      01-12-2013
On Fri, Jan 11, 2013 at 6:01 AM, Rick Johnson
<(E-Mail Removed)>wrote:

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

 
Reply With Quote
 
 
 
 
88888 Dihedral
Guest
Posts: n/a
 
      01-13-2013
Chris Angelico於 2013年1月12日星期*UTC+8下午12時40分36 寫道:
> On Sat, Jan 12, 2013 at 3:34 PM, Rick Johnson
>
> <(E-Mail Removed)> wrote:
>
> > *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

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.



 
Reply With Quote
 
88888 Dihedral
Guest
Posts: n/a
 
      01-13-2013
Chris Angelico於 2013年1月12日星期*UTC+8下午12時40分36 寫道:
> On Sat, Jan 12, 2013 at 3:34 PM, Rick Johnson
>
> <(E-Mail Removed)> wrote:
>
> > *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

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.



 
Reply With Quote
 
Rick Johnson
Guest
Posts: n/a
 
      01-14-2013
On Saturday, January 12, 2013 12:45:03 AM UTC-6, Steven D'Aprano wrote:
> On Fri, 11 Jan 2013 20:34:20 -0800, Rick Johnson wrote:
> > [...]

> So what do you do for, say, os.path? According to the first rule, you
> must write it as osath 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!

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


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 ****ing 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()
 
Reply With Quote
 
Steven D'Aprano
Guest
Posts: n/a
 
      01-14-2013
On Sun, 13 Jan 2013 21:22:57 -0800, Rick Johnson wrote:

> On Saturday, January 12, 2013 12:45:03 AM UTC-6, Steven D'Aprano wrote:
>> On Fri, 11 Jan 2013 20:34:20 -0800, Rick Johnson wrote:
>> > [...]

>> So what do you do for, say, os.path? According to the first rule, you
>> must write it as osath 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 osath

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


--
Steven
 
Reply With Quote
 
Ian Kelly
Guest
Posts: n/a
 
      01-14-2013
On Sun, Jan 13, 2013 at 10:22 PM, Rick Johnson
<(E-Mail Removed)> 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 "osath" 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.
 
Reply With Quote
 
Ian Kelly
Guest
Posts: n/a
 
      01-14-2013
On Mon, Jan 14, 2013 at 11:51 AM, Ian Kelly <(E-Mail Removed)> wrote:
>> 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.


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.
 
Reply With Quote
 
D'Arcy J.M. Cain
Guest
Posts: n/a
 
      01-14-2013
On Mon, 14 Jan 2013 11:51:50 -0700
Ian Kelly <(E-Mail Removed)> wrote:
> On Sun, Jan 13, 2013 at 10:22 PM, Rick Johnson
> <(E-Mail Removed)> wrote:

....Whatever

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

--
D'Arcy J.M. Cain <(E-Mail Removed)> | Democracy is three wolves
http://www.druid.net/darcy/ | and a sheep voting on
+1 416 425 1212 (DoD#0082) (eNTP) | what's for dinner.
IM: http://www.velocityreviews.com/forums/(E-Mail Removed)
 
Reply With Quote
 
Ian Kelly
Guest
Posts: n/a
 
      01-14-2013
On Mon, Jan 14, 2013 at 12:35 PM, D'Arcy J.M. Cain <(E-Mail Removed)> wrote:
> On Mon, 14 Jan 2013 11:51:50 -0700
> Ian Kelly <(E-Mail Removed)> wrote:
>> On Sun, Jan 13, 2013 at 10:22 PM, Rick Johnson
>> <(E-Mail Removed)> wrote:

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


Sorry about that. I actually have him filtered out too, but then I
see other people's responses and I get sucked in.
 
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