Can decorator syntax do this ? (annotated results' names)

[Sakesun Roykiattisak]

I have developed a framework to ease my database programming job, called
"DescribedData Framework"
which use inspection on function/method parameter-name to simplify my code.
for example:

--------
connection = dbi.connect('database-connection-string')
cursor = connection.cursor()
cursor.execute('select TITLE, NAME, AGE from PEOPLE')

descdata = DescribedData(cursor.description, cursor.fetchall())

def show(TITLE, NAME, AGE): print '%s %s %s' % (TITLE, NAME, AGE)

# print all records
print 'Show all data'
descdata.perform(show)

# filter
def teenage(AGE): return AGE <= 19
fdata = FilteredData(teenage, descdata)
print 'Show teenages'
fdata.perform(show)

#sort
def compare_age(AGE1, AGE2): return cmp(AGE1, AGE2)
sdata = SortedData(compare_age, fdata)
print 'Show sorted teenages'
sdata.perform(show)
--------


FilteredData & SortedData are handy decorators for DescribedData
But when I implement more kind of decorators like "JoinedData",
parameter-name inspection is no longer sufficient,
function's *result-name* also have to be inspected.
Currently, I use class instead of function, like this:

--------
class ExtraNameJoiner(object):
def join(self, NAME): return NAME.upper(), NAME.lower(), NAME.capitalize()
def get_joining_description(self): return 'UPPER_NAME', 'LOWER_NAME',
'CAPITALIZED_NAME'

joiner = ExtrasNameJoiner()
jdata = JoinedData(joiner, sdata) # join extra fields
def show_extra(NAME, UPPER_NAME, LOWER_NAME, CAPITALIZED_NAME):
print '%s %s %s %s' % (NAME, UPPER_NAME, LOWER_NAME, CAPITALIZED_NAME)
jdata.perform(show_extra)
--------


The question is: Can the upcomming decorator-syntax be applied in this
situation ?

Can I do something like this :

--------
@resultnames('UPPER_NAME', 'LOWER_NAME', 'CAPITALIZED_NAME')
def join_extra_name(NAME):
return NAME.upper(), NAME.lower(), NAME.capitalize()

jdata = JoinedData(join_extra_name, sdata)
--------


I stopped follow decorator-syntax discussion for a while, because it
seems everlasting.
But now look like it's settle, so I wonder how far can I go with this
new feature ?

 

[Christopher T King]

I stopped follow decorator-syntax discussion for a while, because it
seems everlasting.
But now look like it's settle, so I wonder how far can I go with this
new feature ?

Oh, you don't know how wrong you are All Guido's allowance of the @
syntax into 2.4a2 did was reignite debate, with no end in sight (unless he
pushes it through to 2.4 final, something I sincerely hope he doesn't).
If I were you, I'd hold off on using decorators until they're in a stable
branch, since there's a good chance they might disappear in 2.4a3.

To answer your question, decorators allow for pretty much anything you can
define a function to do; the code in your example will work, provided you
provide a suitable definition for resultnames(): it must return a function
that accepts a function and returns a (mangled version of that) function.