Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]


Groups > comp.lang.python > #36605 > unrolled thread

PyWart: Module access syntax

Started byRick Johnson <rantingrickjohnson@gmail.com>
First post2013-01-10 22:01 -0800
Last post2013-01-12 12:16 +0000
Articles 4 on this page of 24 — 8 participants

Back to article view | Back to comp.lang.python


Contents

  PyWart: Module access syntax Rick Johnson <rantingrickjohnson@gmail.com> - 2013-01-10 22:01 -0800
    Re: PyWart: Module access syntax Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2013-01-11 16:02 +0000
      Re: PyWart: Module access syntax Rick Johnson <rantingrickjohnson@gmail.com> - 2013-01-11 20:34 -0800
        Re: PyWart: Module access syntax Chris Angelico <rosuav@gmail.com> - 2013-01-12 15:40 +1100
          Re: PyWart: Module access syntax Rick Johnson <rantingrickjohnson@gmail.com> - 2013-01-11 21:46 -0800
            Re: PyWart: Module access syntax Chris Angelico <rosuav@gmail.com> - 2013-01-12 16:59 +1100
            Re: PyWart: Module access syntax Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2013-01-12 06:53 +0000
          Re: PyWart: Module access syntax Rick Johnson <rantingrickjohnson@gmail.com> - 2013-01-11 21:46 -0800
          Re: PyWart: Module access syntax 88888 Dihedral <dihedral88888@googlemail.com> - 2013-01-12 16:02 -0800
          Re: PyWart: Module access syntax 88888 Dihedral <dihedral88888@googlemail.com> - 2013-01-12 16:02 -0800
        Re: PyWart: Module access syntax Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2013-01-12 06:45 +0000
          Re: PyWart: Module access syntax Rick Johnson <rantingrickjohnson@gmail.com> - 2013-01-13 21:22 -0800
            Re: PyWart: Module access syntax Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2013-01-14 17:34 +0000
              Re: PyWart: Module access syntax Rick Johnson <rantingrickjohnson@gmail.com> - 2013-01-14 23:07 -0800
            Re: PyWart: Module access syntax Ian Kelly <ian.g.kelly@gmail.com> - 2013-01-14 11:51 -0700
              Re: PyWart: Module access syntax Rick Johnson <rantingrickjohnson@gmail.com> - 2013-01-14 23:49 -0800
                Re: PyWart: Module access syntax Chris Angelico <rosuav@gmail.com> - 2013-01-15 19:08 +1100
              Re: PyWart: Module access syntax Rick Johnson <rantingrickjohnson@gmail.com> - 2013-01-14 23:49 -0800
            Re: PyWart: Module access syntax Ian Kelly <ian.g.kelly@gmail.com> - 2013-01-14 12:04 -0700
            Re: PyWart: Module access syntax "D'Arcy J.M. Cain" <darcy@druid.net> - 2013-01-14 14:35 -0500
            Re: PyWart: Module access syntax Ian Kelly <ian.g.kelly@gmail.com> - 2013-01-14 13:38 -0700
        Re: PyWart: Module access syntax Ian Kelly <ian.g.kelly@gmail.com> - 2013-01-11 23:55 -0700
        Re: PyWart: Module access syntax alex23 <wuwei23@gmail.com> - 2013-01-11 23:36 -0800
    Re: PyWart: Module access syntax Nicholas Cole <nicholas.cole@gmail.com> - 2013-01-12 12:16 +0000

Page 2 of 2 — ← Prev page 1 [2]


#36818

FromIan Kelly <ian.g.kelly@gmail.com>
Date2013-01-14 13:38 -0700
Message-ID<mailman.517.1358195942.2939.python-list@python.org>
In reply to#36768
On Mon, Jan 14, 2013 at 12:35 PM, D'Arcy J.M. Cain <darcy@druid.net> wrote:
> On Mon, 14 Jan 2013 11:51:50 -0700
> Ian Kelly <ian.g.kelly@gmail.com> wrote:
>> On Sun, Jan 13, 2013 at 10:22 PM, Rick Johnson
>> <rantingrickjohnson@gmail.com> 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.

[toc] | [prev] | [next] | [standalone]


#36683

FromIan Kelly <ian.g.kelly@gmail.com>
Date2013-01-11 23:55 -0700
Message-ID<mailman.434.1357973780.2939.python-list@python.org>
In reply to#36665
On Fri, Jan 11, 2013 at 9:34 PM, Rick Johnson
<rantingrickjohnson@gmail.com> 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 "<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.

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

[toc] | [prev] | [next] | [standalone]


#36686

Fromalex23 <wuwei23@gmail.com>
Date2013-01-11 23:36 -0800
Message-ID<3e6681dc-b5e3-45b5-b097-595f9e9479d8@y5g2000pbi.googlegroups.com>
In reply to#36665
On 12 Jan, 14:34, Rick Johnson <rantingrickjohn...@gmail.com> 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.

[toc] | [prev] | [next] | [standalone]


#36698

FromNicholas Cole <nicholas.cole@gmail.com>
Date2013-01-12 12:16 +0000
Message-ID<mailman.443.1357992983.2939.python-list@python.org>
In reply to#36605

[Multipart message — attachments visible in raw view] — view raw

On Fri, Jan 11, 2013 at 6:01 AM, Rick Johnson
<rantingrickjohnson@gmail.com>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.

[toc] | [prev] | [standalone]


Page 2 of 2 — ← Prev page 1 [2]

Back to top | Article view | comp.lang.python


csiph-web