Although it can seem like a CS excercise, everyone will sooner or later have to write a "flatten" function -- a function that takes a nested "list" and makes it one-dimensional:
PYTHON:
-
>>> flatten([1,2, [3,4], 5])
-
[1, 2, 3, 4, 5]
it should also handle Python datatypes in a reasonable manner:
PYTHON:
-
>>> flatten(['hello', 'world'])
-
['hello', 'world']
-
>>> flatten(i**2 for i in range(10))
-
[0, 1, 4, 9, 16, 25, 36, 49, 64, 81]
The trick to the implementation is to realize that everything that is iterable should be flattened... except strings and unicode. To test if something is iterable, call iter on it and be prepared to catch a TypeError: iterator over non-sequence. To test if something is string or unicode use isinstance(item, basestring). That results in something like this:
PYTHON:
-
def flatten(lst):
-
def _flatten(lst, res):
-
for item in lst:
-
if isinstance(item, basestring):
-
res.append(item)
-
else:
-
try:
-
_flatten(iter(item), res)
-
except TypeError: # iterator over nonsequence
-
res.append(item)
-
return res
-
return _flatten(lst, [])
That generates the entire list in the res variable of the inner function as it's recursing through the datastructure. That could be a very long list, so perhaps a generator works better?:
PYTHON:
-
def flatten(lst):
-
for item in lst:
-
if isinstance(item, basestring):
-
yield item
-
else:
-
try:
-
flatten(iter(item))
-
except TypeError: # iterator over nonsequence
-
yield item
-
return
That looks pretty good 
So what was the reason I had to write flatten this time?...
PYTHON:
-
>>> from html import table, tr, td
-
>>> td_num = html.mktag('td', width="20%", style="background:aqua")
-
>>> table(tr(td_num(x), td(x**2)) for x in range(6))
Which gives
| 0 |
0 |
| 1 |
1 |
| 2 |
4 |
| 3 |
9 |
| 4 |
16 |
| 5 |
25 |
the __str__ for all the classes is only defined for the base class, which needed to flatten its contents...
Most attempts at making it easier to define properties in Python seem to quickly descend into metaclass obscurity. Metaclasses can surely solve the problem for an appropriate definition of solve, but "Explicit is better than implicit", and "Simple is better than complex," so none of the metaclass solutions (mine included) have had great appeal. It's always fun to visit the Cookbook, and today I found a great recipe from Sean Ross at http://aspn.activestate.com/ASPN/Cookbook/Python/Recipe/205183.
To recap, the traditional way of defining properties looks something like this
PYTHON:
-
class MyClass(object):
-
def __init__(self):
-
self._foo = "foo"
-
-
def getfoo(self):
-
return self._foo
-
def setfoo(self, value):
-
self._foo = value
-
def delfoo(self):
-
del self._foo
-
foo = property(getfoo, setfoo, delfoo, "property foo's doc string")
All the getters and setters pollute your class namespace (think about adding a bar property), visually there is no Pythonic grouping of the code that belongs to the property, and you don't really know that it's going to be a property until the end.
At the end of the recipe Sean says that if decorators are accepted (they were) his idiom would be even better, so here's my attempt:
PYTHON:
-
# a simple decorator
-
def defprop(doc):
-
def _defprop(fn):
-
return property(doc=doc, **fn())
-
return _defprop
-
-
class MyClass(object):
-
def __init__(self):
-
self._x = 42
-
-
@defprop("The answer to life the universe and Everything")
-
def foo():
-
def fget(self):
-
return self._x
-
def fset(self, v):
-
self._x = v
-
return locals()
Overall, I think it doesn't suck too bad. The name defprop is based on the fact that def is an abbreviation also and property is taken.
Update: turns out I've found it easier to not use the decorator, just like the recipe mentioned above:
PYTHON:
-
class MyClass(object):
-
def __init__(self):
-
self._x = 42
-
-
def foo():
-
def fget(self):
-
return self._x
-
def fset(self, v):
-
self._x = v
-
return locals()
-
foo = property(**foo())
it's an easy idiom to remember, easier than writing the property from scratch, and apparantly easier than figuring out where to put a property so that it will be available everywhere I happen to be...