[Python-ideas] namedtuple is not as good as it should be
Andrew Barnert
abarnert at yahoo.com
Mon Jun 10 08:47:46 CEST 2013
On Jun 9, 2013, at 23:28, Christian Tismer <tismer at stackless.com> wrote:
> But when you continue and create tables, which are typically not having
> a static class definition and you come from the dynamic of tuples,
> the problem suddenly becomes very visible.
>
> The whole issue is that a dynamically usable structure like tuple suddenly
> becomes statically defined, and you need to cope with that.
If your structure is dynamic, shouldn't you be using mapping syntax rather than attribute syntax anyway? After all, you can't write row.last_name unless you know last_name statically, and you wouldn't want to write getattr(row, namefield) in place of row[namefield].
In other words, I think you just want OrderedDict here, or maybe something like sqlite3.Row.
Also, tuples themselves are normally used for static structures—you know you're getting back 4 values, and tup[1] is the last name, etc. Of course you _can_ use them just as "frozen lists", but that's not the paradigm case that we should be looking to extend to new types.
I realize that if you're building an ORM library, or a bridge library like appscript or win32com, you need to create things dynamically that will be used as static objects by the client code, even though you don't know the structure inside the library until runtime. But I think that's a special case.
More information about the Python-ideas
mailing list