namedtuple difference with CPython

[dwhall256]

MicroPython v1.9.4-787-gda72bb683 on 2019-01-23; darwin version
Use Ctrl-D to exit, Ctrl-E for paste mode
>>> from ucollections import namedtuple
>>> Event = namedtuple("Event", ["signal", "value"])
>>> Event.EMPTY = Event("EMPTY", None)
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
AttributeError: 'type' object has no attribute 'EMPTY'

To try to fix this in the VM, I tried copying objtype.c type_attr(), the code below // delete/store attribute
into objnamedtuple.c namedtuple_attr() below // delete/store attribute.
But I still get the same exception. Any tips (better code to follow to set the attr)?

thanks,

!!Dean

[stijn]

I think modifying namedtuple_attr has no effect because that's not what is being called for Event.EMPTY = ...., you're assigning to the type there, not to an actual tuple instance. Best to run this in a build which has MICROPY_DEBUG_VERBOSE defined and/or under a debugger, to see what really goes on.

[dwhall256]

I have investigated further via a debugger. The (trimmed) callstack is:
type_attr() // objtype.c
mp_store_attr()
mp_execute_bytecode() // BC_STORE_ATTR

Inside type_attr(), the self_in argument's locals_dict is NULL. The function's logic prevents storing the attribute and leaves the dest[0] argument as non-null (indicates the error which results in the exception). I can take a stab at "fixing this", but I can estimate three options:
1) create a new locals_dict when the namedtuple type object is created. But this consumes RAM.
2) create a new locals_dict inside type_attr() when a store is attempted and locals_dict is NULL. But are there cases where we don't want this to happen?
3) leave it as-is to preserve MP code size and RAM consumption. Request the users find a workaround.

[stijn]

But are there cases where we don't want this to happen?

I think this is the key question. Don't have an answer for it, couldn't immediately find any other types without locals_dict either. But anyway if this is more general than just namedtuple (i.e. there's other types which have the same incompatibility with CPython), then option 1 is too specific and the more general option of 'allow storing attributes in all types' should be implemented instead. Conditionally enabled in the build under MICROPY_CPYTHON_COMPAT or even more specific so people who don't want/need it do not pay for it.

If you want to take this further I'd suggest you either implement it and create a PR or else just a bug/new feature request, so it's more 'official' and can be discussed on github.

[pfalcon]

3) leave it as-is to preserve MP code size and RAM consumption. Request the users find a workaround.

Please leave it be. And not just namedtuple, but other parts of MicroPython as micro too. If you need CPython bloat, please use CPython. If you can't use CPython, please appreciate minimality and efficiency of MicroPython. More details: https://github.com/micropython/micropyt ... Guidelines

[pfalcon]

Oh, and welcome to MicroPython! Wouldn't ever think that a question like that would come from the PyMite author . To add or not to add? Of course not! We've got exceptions, that's where it stops (almost) .