• 11

A PHP Error was encountered

Severity: Notice

Message: Undefined index: userid

Filename: views/question.php

Line Number: 191


File: /home/prodcxja/public_html/questions/application/views/question.php
Line: 191
Function: _error_handler

File: /home/prodcxja/public_html/questions/application/controllers/Questions.php
Line: 433
Function: view

File: /home/prodcxja/public_html/questions/index.php
Line: 315
Function: require_once

From PEP 8:

  • _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.

Also, from David Goodger's Code Like a Pythonista:

Attributes: interface, _internal, __private

But try to avoid the __private form. I never use it. Trust me. If you use it, you WILL regret it later.


People coming from a C++/Java background are especially prone to overusing/misusing this "feature". But __private names don't work the same way as in Java or C++. They just trigger a name mangling whose purpose is to prevent accidental namespace collisions in subclasses: MyClass.__private just becomes MyClass._MyClass__private. (Note that even this breaks down for subclasses with the same name as the superclass, e.g. subclasses in different modules.) It is possible to access __private names from outside their class, just inconvenient and fragile (it adds a dependency on the exact name of the superclass).

The problem is that the author of a class may legitimately think "this attribute/method name should be private, only accessible from within this class definition" and use the __private convention. But later on, a user of that class may make a subclass that legitimately needs access to that name. So either the superclass has to be modified (which may be difficult or impossible), or the subclass code has to use manually mangled names (which is ugly and fragile at best).

There's a concept in Python: "we're all consenting adults here". If you use the __private form, who are you protecting the attribute from? It's the responsibility of subclasses to use attributes from superclasses properly, and it's the responsibility of superclasses to document their attributes properly.

It's better to use the single-leading-underscore convention, _internal. "This isn't name mangled at all; it just indicates to others to "be careful with this, it's an internal implementation detail; don't touch it if you don't fully understand it". It's only a convention though.

  • 244
Reply Report
      • 1
    • I don't really follow the explanation of why to not use private methods - I mean the exact same argument could be made in Java and Co, but so far java programs still work although they use lots of private methods (which can't be used by subclasses)
      • 1
    • @Voo Sure, they work, but it's a pain in the backside, and frankly mostly just leads to needless pontificating in the Java community.
      • 1
    • In other languages, changing a field/method from private to public just means a one-line change (change the "private" keyword to "public" in the definition). In Python, you have to change the attribute name, which means changing it also where it is called. Not exactly a PITA, but still more bug-prone.
    • I agree with "we're all consenting adults here", but since latebinding is supported by python, this can be dangerous. You can accidentially override methods of subclasses and therefore break the code. Nothing will tell you that you did so and it will be very hard to find out. IDEs should support warnings for that matter. Does anybody know a good IDE that supports such warnings? Like Visuial Studio does that for c#.

A single leading underscore is simply a convention that means, "You probably shouldn't use this." It doesn't do anything to stop someone from using the attribute.

A double leading underscore actually changes the name of the attribute so that two classes in an inheritance hierarchy can use the same attribute name, and they will not collide.

  • 115
Reply Report
    • I love this explanation!! So short & sweet, but gets the whole concept across clearly. I would only add an example of the name-changing: how __foo() in Class1 and Class2 becomes _Class1__foo() and _Class2__foo()

There is no access control in Python. You can access all attributes of a class, and that includes mangled names (as _class__variable). Concentrate on your code and API instead of trying to protect developers from themselves.

  • 11
Reply Report

Trending Tags