module not callable - why not?

[Jack Diederich]

On Fri, Apr 09, 2004 at 02:35:33PM -0400, John Roth wrote:
> 
> "Diez B. Roggisch" <deetsNOSPAM at web.de> wrote in message
> news:c56jph$rrk$05$1 at news.t-online.com...
> > Now usually I'd create a file called "quaternion.py", define my quaternion
> > class in there and then import and create an instance like this:
> >
> > import quaternion
> >
> > q = quaternion.quaternion()
> >
> > Thats a lot to type. doing a
> >
> > from quaternion import quaternion
> >
> > would solve that - but AFAIK thats considered bad for some reasons.
> 
> I don't know why that's bad. Its fairly common in fact.
> What's usually bad is "from foobar import *" which loads
> your module namespace with a bunch of identifiers that
> are not documented in the source of that module, and that
> may change if the imported module changes.
> 
> In fact, I'd probably do: "from quaternion import quaternion as q"
> to minimize typing later.
> 
Naming style and imports came up on python-dev recently.
There were some good suggestions to make life easier:

- Don't name the module and a class in it the same thing
  import Queue # Queue is a module
  from Queue import Queue # Queue is a class
 
  .. 50 lines later ...  

  ob = Queue() # do I want to do this?
  ob = Queue.Queue() # or this?

- Do name modules more generically than the first class you put in them.
  from your example a good name may be 'quatmath' because there will
  also be some methods to manipulate Quaternion instances in there too.
  import quatmath
  q1 = quatmath.Quaternion(a, bi, ck, dk)
  q2 = quatmath.Quaternion(a*2, bi, ck, dk*2)
  result = quatmath.concat(q1, q2)

As a personal preference I'd avoid overriding __add__ __mult__ and
other operators in the Quaternion class.  It is easy to forget what
'q1 * q2' is doing but hard to miss 'quatmath.product(q1, q2)'.

-jackdied