[CentralOH] A simple class to provide named fields

Sam Corder samus at codeargyle.com
Thu Jan 17 02:37:17 CET 2008


I know the idea here is to avoid using indexes on tuples but what is wrong with using a good old fashioned dictionary with strings as keys?  I know the syntax isn't as pretty as a.x but it accomplishes the same thing without the need for a utility class.

----- Original Message -----
From: Brandon Mintern <bmintern at gmail.com>
To: Steven Huwig <steven_h at acm.org>
Cc: centraloh at python.org
Sent: Wednesday, January 16, 2008 8:05:07 PM GMT-0500 Auto-Detected
Subject: Re: [CentralOH] A simple class to provide named fields

Thanks for the quick replies

On Jan 16, 2008 5:57 PM, William McVey <wam at cisco.com> wrote:
>
> I have something similar:
>
>         class Container(object):
<snip>
> It's very similar in concept to yours; however, I tend to prefer classes
> which are tied closer to the data object I'm storing, so I almost always
> subclass Container. In my subclass I define a class attribute named
> 'params' which specifies which parameters/fields I accept. I then go
> about creating a PersonRecord the same way you create your Fields
> objects: For example:
>
>    >>> from wam.Utils import Container
>         >>> class PersonRecord(Container):
>         ...   params = ["fname", "lname", "status"]
>         ...
>         >>> me = PersonRecord(fname="William", lname="McVey", status="Active")
>         >>> me
>         PersonRecord(lname='McVey', status='Active', fname='William')
>         >>> me.status
>         'Active'
>
> The nice thing is that if I try and send down an unexpected field value
> (a sure sign of a bug), I get myself a traceback that indicates what the
> problem is. In the rare cases where I just want a generic
> "accept-anything" object, I just don't define the fields the object
> should be constrained by.
>
> I also really like having __repr__ methods that can recreate the object
> in question.
>
>    -- William
>
> P.S. Note the use of the update() method on the dictionary. That would
> shorten your version to a one liner:
>         def __init__(self, **kwargs): self.__dict__.update(kwargs)

I like the addition of the __repr__ method for sure. I'm not quite as
sure about the subclassing and use of params; I can understand why you
do it, and I see that it works well for you, but my entire thrust was
to avoid the need to have to create special classes for every
different little "Container" in my program. This may not be the best
practice, but it certainly beats indexing tuples.

The __dict__.update suggestion is spot on. Thanks for the suggestion.

On Jan 16, 2008 6:06 PM, Steven Huwig <steven_h at acm.org> wrote:
>
> I like it! My only suggestion would be to name it "Record" instead of
> "Fields", following the description at http://en.wikipedia.org/wiki/
> Record_(computer_science).
>
> -- Steve
>

I like that suggestion. I had been wrestling with what to call it for
quite some time (Fields was about the 3rd name I've used), and Record
is one that I think fits well.

Taking the suggestions of both of you into account, here's what I get:

class Record:
    """
    A class intended to provide a simple interface for creating objects
    with named fields. That is, instead of returning a tuple and indexing
    it or writing a unique class, you can simply do something like:
    a = Record(x=1, y=2)
    a.x # 1
    a.y # 2
    a   # Record(x=1, y=2)
    """
    def __init__ (self, **kwargs):
        self.__dict__.update(kwargs)

    def __repr__ (self):
        return "Record(%s)" \
               % ", ".join(["%s=%s" \
                            % field for field in self.__dict__.iteritems()])
_______________________________________________
CentralOH mailing list
CentralOH at python.org
http://mail.python.org/mailman/listinfo/centraloh



More information about the CentralOH mailing list