Python Is Descendant

How do you check if a given Python object is a descendant of a given class? Here is a good way to do it using the inspect.getmro() function. This function returns a list of all the object's base classes, including all grand-parent classes, and so on, all the way up the class hierarchy.

Here is my version of the technique put into a simple function that will test if the specified object is a descendant of the specified class name.

from inspect import getmro

def istype(obj, typename):
  return typename in [clsobj.__name__ for clsobj in getmro(obj.__class__)]

class A(object):
  pass

class B(A):
  pass

if __name__ == "__main__":
  print istype(B(), "A")
  print istype(B(), "object")

Exceptional Development

Exceptions are raised when an exceptional condition is true within a program. Most object-oriented languages define a base exception class which developers can use to derive custom exception hierarchies.

These exception hierarchies can grow to be quite large, even in production systems. This makes sense if we want to use the exception handling mechanism in a polymorphic way. We handle all exceptions at one level of the hierarchy, including all descendant exceptions, while ignoring all exceptions at a higher level up.

These hierarchies allow us to reason about what as gone wrong. So using an aggressive approach to exception handling during initial development might make a lot of sense. Construct a list of every conceivable exceptional path that isn't part of the successful path. Generalize some of the exceptions so you avoid unnecessary duplication.

With this first initial exception hierarchy, you can pound out a first iteration quickly. The fact that none of these exceptions in the hierarchy are raised is an indicator that the iteration is complete.

Simple Code Editors

This question on Slashdot asks about VIM text editing capabilities in more modern integrated development environments. The answers to the question seems to indicate that a number of options are available for those that want to bring development capabilities to newer code editors.

So, is it that we want to bring enhanced text editing capabilities, that have worked for years with VIM, into an IDE? Or should this text-editing capability be brought to the more modest code editors, not necessarily IDEs.

In most cases, integrated development environments get in the way more than they lend a hand in producing quality code. In other, niche, cases, they can be the perfect tool for the job.

So what is wrong with VIM exactly? Nothing. That is, there is nothing wrong with VIM for using it as a simple code editor. It just so happens that simple code editors are in huge demand these days and so VIM is still the editor of choice for many developers for its advanced text editing capabilities.

I find the main beneficial feature that newer code editors bring to the table are hierarchical class navigators. It isn't a matter of being able to navigate by class; VIM can do that. It is more a matter of being able to visualize the classes in the given more you are editing.

Exploring Application Menu Data Structures

All modern GUI applications have menus in one form or another. These menus offer the end user an easy way to navigate throughout the application while consuming minimal real estate. This is achieved because menus in applications are often hierarchical, which means that only the top level of the hierarchy needs to be displayed when the menu is not being navigated. Not only do menus help make efficient use of the application GUI space, but they also help with the logical organization of the actions the user may perform within the application. As the user navigates to lower levels in the hierarchy, the more specific the available actions become. Horizontal, desktop-like menus are becoming more frequent in web browser GUI applications. This further complicates the task of designing a portable menu data structure.

The hierarchical menu data structure is by far the most commonly encountered menu structure. The data structure for GUI menus changes drastically when the structure is built dynamically verses a static menu structure. For statically built menus, which are represented by HTML, there is no concern about changing menu items. Although this approach is a poor design, the developer simply edits the HTML menu structure to add in the new menu items as needed. With static menus such as these, the structure is entirely dictated by the surrounding page and CSS styles. Another reason for avoiding static menu data structures. Consider the requirement of dynamically building a menu data structure that is functional for both hierarchical and non-hierarchical menu styles. If the data structure used for this is dynamically constructed, it can be reused. If we want to use this dynamic menu-building code to construct a single-level GUI menu, we simply use the code to build hierarchy data structure with multiple roots an no children. However, this calls for flexible presentation code which transforms the data structure into the GUI. This is another challenging problem in its' own right.

Here is an example data structure that could potentially be used to build a GUI menu.

{\
  "File":[{"Exit":{"action":exit()}}],\
  "Edit":[{"Heading":[{"H1":{action:h1()}},\
                      {"H2":{"action":h2()}}]\
         }]\
}

Here, we have two root elements in the hierarchy. Here is another example of representing the same menu data structure.

[
   {"title":"File",\
    "children":[{"title":"Exit",\
                 "action":exit()}]},\
   {"title":"Edit",\
    "children":[{"title":"Heading",\
                 "children":[{"title":"H1",\
                              "action":h1()},\
                             {"title":"H2",\
                              "action":h2()}]\
               }]\
   }\
]

Here, children are explicitly specified for each node in the hierarchy. Both approaches are valid ones, one preferred by one developer over the other. However, the boss of what this data structure should look like, ultimately, is the code that uses it to build the GUI menu.

The chief idea behind using data structures such as these, and building them dynamically, is to achieve better portability and reuse with GUI code. However, much GUI code, especially in web applications, change the menu data structure simply to change the style of the GUI. This is invalid since the menu items do not change. It would be much nicer, for developers hailing from all walks of life, if a consistent GUI menu data structure could be used and reused. This is especially important for cross-browser compatibility in web applications. The good news is that many modern javascript toolkits support the notion of widgets. The widgets within these widget sets comply with one another to offer a consistent style framework. This gives developers an opportunity to use a consistent menu data structure. Widgets aren't always needed for this purpose. If developers write their own code to build the intermediary HTML representation of the menu data structure, that works too. Just be consistent about it.