Decorator syntax (was Re: PEP 318 - PyFIT comments)

John Roth newsgroups at
Fri Aug 6 15:05:57 CEST 2004

"Michael Hudson" <mwh at> wrote in message
news:m3wu0csetn.fsf at
> This reply was a touch more hostile that I was expecting; if I've hit
> some nerve, sorry, if not, err, can you relax a bit?
> "John Roth" <newsgroups at> writes:
> > "Michael Hudson" <mwh at> wrote in message
> > news:m3pt65g4hb.fsf at
> >
> > > Well, that would be because that's impossible :-)
> >
> > I wish you'd have told me that before I did it. As I said in
> > a prior post, I had to put a general metadata facility into
> > PyFIT, and it's working quite nicely, thank you.
> OK, poor choice of words.
> [snippity]
> > > What kind of metadata do you want?
> >
> > Type and other declaration information for any identifiers
> > that will be referenced in the FIT tests. Other information
> > includes things like precision for floating point numbers,
> > strings that are accepted as "true" or "false" for booleans,
> > the subtype for lists and tuples, references to custom
> > type adapters and other stuff.
> So, you would like to write
> class Thiny(object):
>     @attribute(type=float, precision=3)
>     a = 1.23
> ?
> I really don't see how you could make that work.  attribute() could
> return something that was called with the dictionary being inserted
> into, the string 'a' and the value 1.23, but... ick.  I don't think I
> like that idea.  What would you find helpful?

Well, what I need here is very simple. If the FIT test contains
a column labeled "a", then I need to find the type. If it's a float,
I need to find the default precision for the compare. (Actually,
float is a poor choice here - I fixed the need to have a precision
by using the precision information in the text version of the float,
but that's a different conversation.)

What I'm doing right now is this:

class fubar:
    _typeDict = {}
    _typeDict['a'] = "float"
    _typeDict['a.precision'] = 3

Note that I'm not defining 'a' on the class level. Whether or not
I need a default value is a purely tactical decision that's orthogonal
to the need for metadata in this application.

A somewhat better (if whimsical) example of the need for
structured metadata is:

    _typeDict['b'] = "boolean"
    _typeDict['b.false'] = "fubar"

This makes the boolean type adapter accept the string 'fubar'
as 'false'. (It doesn't make it print it that way, though.)

Or a much more pedestrian example:

    _typeDict['d'] = "date"
    _typeDict['d.parse'] = "some %format string"
    _typeDict['d.print'] = 'some other %format string'

The operands being, of course, something you can feed to the
appropriate functions in the time or datetime modules.

Notice that in all three cases I want to associate several pieces of
metadata with an identifier in the class. I don't want to associate
it with a particular object (although there are other applications that
would want to do that, especially for functions).

Also note that one of the two pieces of metadata is probably generally
useful (the type). The other is highly specific to my application.

John Roth

> Cheers,
> mwh
> -- 
>   ... but I'd rather not reinvent the wheel if I don't have to.  On
>   the other hand, if the currently instantiated version of the wheel
>   consists of a square rock covered with moss, I might as well just
>   start fresh.                          -- Roy Smith, comp.lang.python

More information about the Python-list mailing list