[Gzz-commits] gzz/doc/pegboard/coding_standard--vegai peg.rst

[Vesa Kaihlavirta]

CVSROOT:        /cvsroot/gzz
Module name:    gzz
Changes by:     Vesa Kaihlavirta <address@hidden>       03/02/05 08:44:06

Modified files:
        doc/pegboard/coding_standard--vegai: peg.rst 

Log message:
        Example of from blaa import * + fixes based on discussion

CVSWeb URLs:
http://savannah.gnu.org/cgi-bin/viewcvs/gzz/gzz/doc/pegboard/coding_standard--vegai/peg.rst.diff?tr1=1.14&tr2=1.15&r1=text&r2=text

Patches:
Index: gzz/doc/pegboard/coding_standard--vegai/peg.rst
diff -u gzz/doc/pegboard/coding_standard--vegai/peg.rst:1.14 
gzz/doc/pegboard/coding_standard--vegai/peg.rst:1.15
--- gzz/doc/pegboard/coding_standard--vegai/peg.rst:1.14        Wed Feb  5 
03:04:49 2003
+++ gzz/doc/pegboard/coding_standard--vegai/peg.rst     Wed Feb  5 08:44:06 2003
@@ -3,8 +3,8 @@
 =============================================================
 
 :Author:   Vesa Kaihlavirta
-:Last-Modified: $Date: 2003/02/05 08:04:49 $
-:Revision: $Revision: 1.14 $
+:Last-Modified: $Date: 2003/02/05 13:44:06 $
+:Revision: $Revision: 1.15 $
 :Status:   Incomplete
 :Scope:           Minor
 :Type:     Policy
@@ -37,9 +37,58 @@
     RESOLVED: a conversion tool at "make committable" will
     convert tabs into 8 spaces
 
-- import grouping is not resolved?
+- how should the import statements be grouped?
 
-- Rule 1 needs rationale
+    - Benja: "I'd prefer first gzz, then java, for consistency with Java files 
and 
+      because this makes those imports rest in alphabetical order. (Hmm, come 
+      to think of it, I would like to have that rule included: In each group, 
+      imports should be in alphabetical order.)"
+
+    - Tuomas: "I disagree: more importantly it should be "foreign stuff" "our 
stuff"."
+
+    I feel that the order of grouping is less important than the actual
+    grouping. How about defining the imports as a set of sets?
+
+- does every file need to have its module name in the headers?
+
+    [ponder about lava/ and basalt/, otherwise "RESOLVED: No."]
+
+- What case rules should be observed for variables and functions and
+  modules?
+
+    RESOLVED: modules should be lowercase and variables and functions
+    mixedCase. This is the convention that is used in Java and we want 
+    to keep our Java and python code as closely readable as possibly.
+
+- should "from bar import *" be allowed when importing from current package?
+
+    It depends. This is a potential namespace clutterer, and makes code less
+    clear, especially for first-time readers, eg.::
+
+        [./foo.py:]
+        def a(): print "foo.a"
+
+        [./blaa.py:]
+        def a(): print "blaa.a"
+       def b(): print "blaa.b"
+        
+        [./program.py:]
+        from . import *    # can't import from . really, this line is 
pseudocode
+
+        a()                # the reader of program.py can not tell where a() 
+        b()                # and b() are coming from.
+
+    On the other hand, more verbose code is not always very elegant, eg::
+
+        [gzz/views/buoy/program.py:]
+        import gzz.views.buoy
+     
+        gzz.views.buoy.a()
+        gzz.views.buoy.b()        
+
+    [add something to conclude this]
+
+            
 
 Changes
 =======
@@ -52,7 +101,7 @@
 2. Header comments should include authors.
 
 3. After header comments, rcsId:
-   rcsId = "$Id: peg.rst,v 1.14 2003/02/05 08:04:49 Vegai Exp $"
+   rcsId = "$Id: peg.rst,v 1.15 2003/02/05 13:44:06 Vegai Exp $"
 
 4. After rcsid, the imports (unless there's a good reason to delay
    importing).
@@ -98,8 +147,6 @@
     
 Notes
 =====
-
-- items 8 and 9 are arbitrary choices for the sake of consistency
 
 - "A Foolish Consistency is the Hobgoblin of Little Minds" - Ralph Waldo 
Emerson