Re: PyWart: Module access syntax
On Thu, 10 Jan 2013 22:01:37 -0800, Rick Johnson 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 > > 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". -- Steven -- http://mail.python.org/mailman/listinfo/python-list
Re: PyWart: Module access syntax
On Friday, 1-11-2013 10:02:34 AM, Steven D'Aprano wrote: > 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. > > 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?" 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 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!) Traceback (most recent call last): File "", line 1, in 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 single char(colon). The maintainer is the real winner. This is a win-win all around. -- http://mail.python.org/mailman/listinfo/python-list
Re: PyWart: Module access syntax
On Sat, Jan 12, 2013 at 3:34 PM, Rick Johnson 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 -- http://mail.python.org/mailman/listinfo/python-list
Re: PyWart: Module access syntax
On Friday, January 11, 2013 10:40:36 PM UTC-6, Chris Angelico wrote: > On Sat, Jan 12, 2013 at 3:34 PM, Rick Johnson > > *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. What is this importing? "import lib.gui.simpledialog" ...is that the "simpledialog module" or "SimpleDialog object"? Since naming conventions 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 the status quo): 1. Enforce naming conventions. 2. Enforce path syntax. 3. Continue to obfuscate code. The choice is yours. -- http://mail.python.org/mailman/listinfo/python-list
Re: PyWart: Module access syntax
On Sat, Jan 12, 2013 at 4:46 PM, Rick Johnson wrote: > 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 -- http://mail.python.org/mailman/listinfo/python-list
Re: PyWart: Module access syntax
On Fri, 11 Jan 2013 20:34:20 -0800, Rick Johnson wrote: >> > 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?" > > 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 "", line 1, in > 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. -- Steven -- http://mail.python.org/mailman/listinfo/python-list
Re: PyWart: Module access syntax
On Fri, 11 Jan 2013 21:46:36 -0800, Rick Johnson wrote:
> On Friday, January 11, 2013 10:40:36 PM UTC-6, Chris Angelico wrote:
>> On Sat, Jan 12, 2013 at 3:34 PM, Rick Johnson
>
>> > *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.
>
>
> 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)
--
Steven
--
http://mail.python.org/mailman/listinfo/python-list
Re: PyWart: Module access syntax
On Fri, Jan 11, 2013 at 9:34 PM, Rick Johnson wrote: > 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 many > times 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 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!) 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 "", line 1, in > 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. >> 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". 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? -- http://mail.python.org/mailman/listinfo/python-list
Re: PyWart: Module access syntax
On 12 Jan, 14:34, Rick Johnson 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. -- http://mail.python.org/mailman/listinfo/python-list
Re: PyWart: Module access syntax
On Fri, Jan 11, 2013 at 6:01 AM, Rick Johnson 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. -- http://mail.python.org/mailman/listinfo/python-list
Re: PyWart: Module access syntax
Chris Angelico於 2013年1月12日星期六UTC+8下午12時40分36秒寫道： > On Sat, Jan 12, 2013 at 3:34 PM, Rick Johnson > > 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. -- http://mail.python.org/mailman/listinfo/python-list
Re: PyWart: Module access syntax
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 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 are
accessing 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 "", line 1, in
> > 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 an
object. 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 th
Re: PyWart: Module access syntax
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 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). -- Steven -- http://mail.python.org/mailman/listinfo/python-list
Re: PyWart: Module access syntax
On Sun, Jan 13, 2013 at 10:22 PM, Rick Johnson 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
Re: PyWart: Module access syntax
On Mon, Jan 14, 2013 at 11:51 AM, Ian Kelly 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. -- http://mail.python.org/mailman/listinfo/python-list
Re: PyWart: Module access syntax
On Mon, 14 Jan 2013 11:51:50 -0700 Ian Kelly wrote: > On Sun, Jan 13, 2013 at 10:22 PM, Rick Johnson > 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 | 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: da...@vex.net -- http://mail.python.org/mailman/listinfo/python-list
Re: PyWart: Module access syntax
On Mon, Jan 14, 2013 at 12:35 PM, D'Arcy J.M. Cain wrote: > On Mon, 14 Jan 2013 11:51:50 -0700 > Ian Kelly wrote: >> On Sun, Jan 13, 2013 at 10:22 PM, Rick Johnson >> 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. -- http://mail.python.org/mailman/listinfo/python-list
Re: PyWart: Module access syntax
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". pkg1:pkg2:pkgN.member1.member2.memberN -- http://mail.python.org/mailman/listinfo/python-list
Re: PyWart: Module access syntax
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* for access 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 "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 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:
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 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 the
language, 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 shed an old skin
so the new skin can grow.
--
http://mail.python.org/mailman/listinfo/python-list
Re: PyWart: Module access syntax
On Tue, Jan 15, 2013 at 6:49 PM, Rick Johnson
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
--
http://mail.python.org/mailman/listinfo/python-list
Re: PyWart: Module access syntax
> > 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. Is there any way to report a bug to that bot ? I don't know how it end up thinking we where talking about dishes. I hope it won't count this reply as a successful bot post. JM -- IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you. -- http://mail.python.org/mailman/listinfo/python-list
