[melbourne-pug] Coding idiom

[Mike Dewhirst]

Tennessee Leeuwenburg wrote:
> Hi all,
> 
> I've been starting to adopt a new coding idiom, and I thought I'd ask 
> for comments.
> 
> I've been extending some code, which has involved overriding many 
> __doFoo() methods and accessing __myVariable variables. As I understand 
> it, this is stylistically bad, and __XXX is a way of flagging that the 
> thing is private-only. Keep Out Unless Absolutely Necessary.

Here is what PEP 8 has to say ...

( http://www.python.org/dev/peps/pep-0008/ )

... In addition, the following special forms using leading or trailing 
underscores are recognized (these can generally be combined with any 
case convention):

- _single_leading_underscore: weak "internal use" indicator.  E.g. "from 
  M import *" does not import objects whose name starts with an underscore.

- single_trailing_underscore_: used by convention to avoid conflicts 
with Python keyword, e.g.

       Tkinter.Toplevel(master, class_='ClassName')

- __double_leading_underscore: when naming a class attribute, invokes 
name mangling (inside class FooBar, __boo becomes _FooBar__boo; see below).

- __double_leading_and_trailing_underscore__: "magic" objects or 
attributes that live in user-controlled namespaces.  E.g.

       __init__, __import__ or __file__.

Never invent such names; only use them as documented.

Regards

Mike


> 
> I can see a middle ground between the public interface and very private 
> methods. Such a thing might be an element of processing which is 
> typically called privately, but wouldn't be unsafe to call or override 
> in appropriate circumstances.
> 
> For this reason I've been using .XXX for the public interface, ._doFoo() 
> for internal methods which are relatively safe, and .__doFoo() for 
> things intended to be very private.
> 
> Cheers,
> -T
> _______________________________________________
> melbourne-pug mailing list
> melbourne-pug at python.org
> http://mail.python.org/mailman/listinfo/melbourne-pug
> 
>