[Python-ideas] A mutable alternative to namedtuple

anatoly techtonik techtonik at gmail.com
Thu Mar 19 11:23:15 CET 2015


On Wed, Mar 18, 2015 at 2:36 PM, Luciano Ramalho <luciano at ramalho.org> wrote:
> On Wed, Mar 18, 2015 at 3:05 AM, anatoly techtonik <techtonik at gmail.com> wrote:
>> On Tue, Mar 17, 2015 at 7:52 PM, Luciano Ramalho <luciano at ramalho.org> wrote:
>>> Sometimes we need a simple class to hold some mutable attributes,
>>> provide a nice repr, support == for testing, and support iterable
>>> unpacking
>>
>> +1, but I think that the core problem with such proposals is that they
>> lack the use cases. The only reason for me to have such class is to
>> work with tabular data.
>>
>> For example, for querying the capability of the system, I need to build
>> an inmemory table of features, and then set parameters for each
>> feature one by one. sqlite/SQL is an overkill for that, and dicts are
>> just not enough to do readable lookups and updates to specific
>> cells, so I'd more appreciate a full table class than just its "named
>> row" model.
>
> Thanks for your input and example, Anatoly. What would the full table
> class offer that could not be easily done with a simple list of items
> produced with a plainclass class?

Lookup operations. Attaching new columns to existing table or providing
a supplementary table with additional columns for existing ones. If
Python had first class tables, things right now could be very different.

We could have a better structured data handling.

Take logging for example. It is not extensible. You have message and
level. Then it got component. Then timestamp. But you can't add anything
yourself to that message - error code, binary dump, selfie or some read/
unread flags. If logging used a table, there could be an ability to add your
own data to its events. And this would be interoperable between
programs.

>> Practical example that I came up with:
>> https://bitbucket.org/techtonik/discovery/src/c4f3d306bb43772dcf3c03be8db941ff67d077b4/graphics/canvas2d/canvas2d/__init__.py?at=default#cl-22
>
> Oh, I see you have an update method, so that's the key value add of
> the Table class, right?

Right. The update method says "change the value of cell with column
name==name, in row where column name idname==idvalue".

It is basically lookup method with cell modification.

So it adds a second dimension to 1D "mutable namedtuple".

> I see the Table and plainclass as complementary ideas. You could use
> plainclass to implement Table more easily. The Table.__iter__ could
> return plainclass class instances instead of OrderedDict.

That's one of the uses. But I am concerned that it is the only example
where this "mutable namedtuple" is useful.

I don't like the dynamic class construction as with namedtuple. I believe
you can not serialize it reliably, and there are problems with static
analysis tools to deal with it (like locate the definition).
-- 
anatoly t.


More information about the Python-ideas mailing list