Popular style document?

[Andy Gimblett]

On Wed, Mar 20, 2002 at 01:52:35PM +0000, Greg Weeks wrote:

> Is there a popular style document for Python?  I realize that there isn't a
> whole lot of scope for such a thing, but I wondered because of certain
> particular issues that came to mind.

    http://python.sourceforge.net/peps/pep-0008.html
    http://python.sourceforge.net/peps/pep-0257.html

> 1.  I use "me" instead of "self" in method definitions.  I mention this not
> to ask what people think -- I have an unpleasant suspicion -- but because
> I'll be using "me" below.

Bad boy.  :-)

> 2.  How should methods call other methods?  Suppose that show_and_tell()
> simply calls show() and then tell().  Let the class be, say, "Demo".  Then
> there are two choices:
> 
>     def show_and_tell(me):
> 	me.show()
> 	me.tell()

Correct and moral.  :-)

>     def show_and_tell(me):
> 	Demo.show(me)
> 	Demo.tell(me)

Pointless except when Demo is a subclass, AFAIK.  If anyone knows
better, I'd love to hear about it and increase my knowledge.  :-)

> These have different semantics for subclasses, but I would hate to choose
> based on that.  I simply use the first alternative.  But only the second
> alternative was given in "Python Essential Reference" (by David Beazley).
> So I wonder.

Gosh.  That really surprises me.  Are you sure the book wasn't talking
about subclasses at that point?

> 3.  Personally, I think that code is more readable (at least sometimes)
> when global variables are "declared".  But how?  If within a comment, what
> form does the comment take?  Unable to answer that question, I found myself
> using a "global" statement, which is semantically a no-op and only
> acceptable if the reader knows what the heck it is doing there.

The "global" statement certainly isn't a no-op, and it's definitely
not just for readability - it can totally change your program's logic!

Check out the attached global.py for a quick demo of how I tend to use
it.  This isn't the full story but should hopefully convince you it's
not a no-op.

For completeness, here's the output I get when I run global.py:

[gimbo at andy python]$ ./global.py 
Foo: 0
Foo: 1
Foo: 1
vikings inside beans(): 3
vikings outside beans(): 3
vikings outside beans(): 6
vikings inside beans(): 3
Traceback (most recent call last):
  File "./global.py", line 55, in ?
    print dinsdale
NameError: global name 'dinsdale' is not defined

Hope this helps,

Andy

-- 
Andy Gimblett - Programmer - Frontier Internet Services Limited
Tel: 029 20 820 044 Fax: 029 20 820 035 http://www.frontier.net.uk/
Statements made are at all times subject to Frontier's Terms and
Conditions of Business, which are available upon request.
-------------- next part --------------
#!/usr/bin/env python

# I always declare globals at the top, out of force of habit.  But see
# the beans() function, below.

foo = 0

def spam():
    # We use a global declaration to tell spam() that when we say foo,
    # we mean the one defined above.
    global foo
    foo = 1

def eggs():
    # Here, foo is local to eggs(), and the foo defined above is
    # untouched.  So calling eggs() makes no change.
    foo = 2

def beans():
    # Globals can be declared anywhere in a module
    global vikings
    vikings = 3
    print "vikings inside beans(): %d" % (vikings,)

def gumby():
    # If this doesn't get called, referencing dinsdale anywhere else
    # will result in a NameError
    global dinsdale
    dinsdale = 4
    print "Dinsdale in vikings: %d" % (dinsdale,)

# See how foo changes over these calls...

print "Foo: %d" % (foo,)
spam()
print "Foo: %d" % (foo,)
eggs()
print "Foo: %d" % (foo,)

# Now we demonstrate that a global can be defined anywhere.

beans()
print "vikings outside beans(): %d" % (vikings,)

# However, if we modify it here without first declaring global in
# thise scope, we're creating a completely different variable which
# just happens to have the same name, so when we call beans() again,
# it won't have changed since last time.

vikings = 6
print "vikings outside beans(): %d" % (vikings,)
beans()

# Finally, we try to access dinsdale, which fails because gumby()
# hasn't been called yet.

print dinsdale