Namespaces — let’s do more of those! (Python)

Namespaces are one honking great idea — let’s do more of those!
— The Zen of Python (PEP 20) by Tim Peters

In the quest for order and heirarchy in our code, namespaces are our chief weapon (along with fear and surprise). Namespaces come in 2 forms in python: Implicitly inside classes and functions, and explicitly as modules. Subtleties aside, modules are just namespaces with an odd usage: They must be files, and only other modules can parent them.

Of the implicit namespaces, each have their own “quirks”:

• Classes – these namespaces have two modes – “normal” and instanciated, and both have odd behaviours.
• Functions – their internal space cannot be accessed from the outside; they only provide locality.

All this babble was meant to demonstrate that these are not enough. You can’t always keep your code organized if your choice is only between file seperation, twisted behaviour or no-public policy.

What else could I possibly want?

Well, for example, dividing responsibilities inside a class. Classes infamously have several responsibilities, and while they all must reside inside the same class, there’s no reason why they should be blended inside each other.
Consider all of the GUI libraries you ever used. Now consider the following hypothetical GUI window:

class YetAnotherGuiWindow(whatever):
    ...
    namespace spatial:
        location = property(_get_loc, _set_loc)
        size = property(_get_size, _set_size)
        def move(self, where_to):
            ...

    namespace visual:
        color = property(_get_color, _set_color)
        ...
    ...

#Somewhere Else
guiwindow.spatial.move( guiwindow.spatial.pos + (5,5) )
guiwindow.visual.color = Colors.Black
...

Think how wonderful it would be to perform dir(guiwindow.visual) and see only visual possiblities, without all the other 500 attributes. Want to find an event? dir(guiwindow.events), it’s a rather short list. It would also be a lot clearer to the reader that when you try to access “background_process” you mean “threads.background_process” and not “cool_visual_filter_effects.background_process”.

There are more examples I could think of.

At this point I can foresee a possible response, that I wish to address in advance. People might propose that I rename methods to fake a namespace, and that the dir listing can work by filtering the names for that fake namespace. This would vaguely emulate what I’m hoping for, but I can’t help comparing it to writing C++ using C structs and function pointers.

I like your idea. Is there anything I can do with what python currently offers?

I have given this some thought. The short answer is: No. Python’s namespaces are crippled, and this cannot be solved.  The long answer is: Maybe, depends on what you want. You could use a class to provide a namespace, in which all methods (perhaps through a decorator for each) would recieve the parent class’ instance as self, rather than their own. This is a bit tedious, as it requires addition to every function, so I tried to see if I can use python’s dynamic and introspective nature to my advantage:

def make_namespace(self, ns_cls):
    "This code iterates all functions in ns_cls and binds them to self"
    for attr_name in dir(ns_cls):
        attr = getattr(ns_cls,attr_name)
        if type(attr) == types.MethodType:
            setattr(ns_cls, attr_name, attr.__get__(self) )

Usage:

class YetAnotherGuiWindow:
    def __init__(self, pos, size, ...):
        ...
        self._size = size
        make_namespace(self, self.spatial)

    class spatial:
        ...
        def get_size(self):
            return self._size
        def set_size(self, size):
            self._size = size

...
#Somewhere Else
guiwindow.spatial.set_size( (100, 100)  )

This seems to work fine for methods, but not for properties.
In fact, I couldn’t manage to write any code that would work for properties. Readers are welcome to see this as a challenge to produce such code. Honorable mentions promised to solvers.

Advertisement

Broken Inheritance

Hello readers, and welcome to my new blog.

Inheritance (of OO) is a tricky business. When creating a sub-class, nothing clear is said about the purpose of this new sub-class, or the relation between it and its parent. One is forced to guess, based on how the sub-class is written and used. This has been well said before, so I will not repeat it. But if it is not clear to humans, why should it be clear to a compiler?

Allow me to be concrete, by telling you my (sad) story. This all started as I was writing a tree class in C#. To simplify matters, suppose that this is how it looked:

class TreeNode
{
    public TreeData data {get; set;};
    public IEnumerable<TreeNode> subnodes();
    public void AddSubNode(TreeData data);
    /* ...
    A lot of useful methods for trees,
    such as bfs/dfs visitors
    ... */
}

This was very useful, but then I needed some new functionality. This functionality did not fit inside Tree (for reasons I will spare you, as you could probably make some up yourself), so I decided to create a new class, called BetterTreeNode.
So, suppose I wrote this code:

class BetterTreeNode : TreeNode
{
    /* ...
    Additional functionality
    ... */
}

I was happy, when horror struck: The class was flawed. I will spare you the detective work (pause now if you want to guess it by yourself): Whenever a method travelled the tree, the subnodes() method would return a TreeNode rather than a BetterTreeNode. Same with other methods. This required an explicit cast after every call to an inherited method. Also, methods such as AddSubNode were written to create a new TreeNode instance. In short, a mess. To solve it, I had the following options:
1. Override (but with the new keyword) every inherited method to return proper values. Rewrite AddSubNode (in the hope that it is possible).
2. Not inherit. Use TreeNode as a shadow tree. This means shadowing all the methods I want to use.
3. Rewrite everything from scratch. While the first two are annoying, this is a complete failure at code-reuse.

But, none of these options seem good; none of them answer my need for an easy and concise code-reuse.
I felt the true solution would be to have the methods automatically re-written to return BetterTreeNode. But here enters the ambiguity and obscureness of inheritance: Perhaps for some methods I would not want it. The compiler cannot guess this.

This problem was demonstrated using C#, but it exists in every statically-typed object-oriented language I know (granted, not that many).

Therefor, I propose for a new functionality for these languages – a “thisclass” keyword.
So this is how I would write TreeNode:

class TreeNode
{
    public TreeData data {get; set;};
    public IEnumerabl<thisclass> subnodes();
    public void AddSubnode(TreeData data)
    {
        ... new thisclass(...) ...
    }
    ...
}

I also have a suggestion: Take another look at code-reuse. Inheritance is a great way to re-use and extend code in classes, but perhaps it is not always the best way. Perhaps other ways should be sought after.