Coverage decreased (-0.14%) to 93.01% when pulling 3c33846 on fakenamedtuple into 2bb5f41 on master.

Nice :-), I'll take a look at it today.

Well, I'd say this is neat solution (so neat, that someone may ask whether we need namedtuple, not fakenamedtuple, but the answer is that of course we need, because each namedtuple should be a separate type, while fakenamedtuple "fakes" it by having all its objects being of same type).

So, I guess the criteria should be: do we get any size savings with this patch, for expected 2-occurrence usage, comparing to encoding those 2 usages as proper namedtuples? If we do, it's certainly worth it.

But then would be nice to have more descriptive name than "fakednamedtuple".

I agree with Paul, the name could be improved.

On Apr 21, 2015, at 1:26 AM, Paul Sokolovsky notifications@github.com wrote:

Well, I'd say this is neat solution (so neat, that someone may ask whether we need namedtuple, not fakenamedtuple, but the answer is that of course we need, because each namedtuple should be a separate type, while fakenamedtuple "fakes" it by having all its objects being of same type).

So, I guess the criteria should be: do we get any size savings with this patch, for expected 2-occurrence usage, comparing to encoding those 2 usages as proper namedtuples? If we do, it's certainly worth it.

But then would be nice to have more descriptive name than "fakednamedtuple".

—
Reply to this email directly or view it on GitHub.

So, I guess the criteria should be: do we get any size savings with this patch

I haven't got precise numbers, but my original calculations said that 2 instances make it just worth it.

There are a few places in stmhal that I would have used a (fake)namedtuple had it been possible to put them in ROM (eg can.recv's return value). I think namedtuples are a great way to allow for new features while retaining backwards compat. Also it allows ports without much space to selectively include only relevant entries in a (fake)namedtuple and still be compatible with a full implementation of that tuple.

And don't forget wifi drivers wanting to use this as return values for scan() and ifconfig() etc.

With this efficient fakenamedtuple (or whatever it'll end up being named) I think we will start to use it liberally without fear of excessive ROM usage and make a much more user-friendly API.

Other name choices:

• namespace
• idtuple
• attrtuple (I like this one)

1. Decide exactly what info to provide in sys.implementation and os.uname() fields. The ones I provided are a good start I think.

I think the ones you already did are good enough for now.

Regarding the name choices, attrtuple is fine. What about statictuple?

I like attrtuple.

statictuple is already a thing, you just make static tuples :) With fakenamedtuple you can make static const versions and instances on the heap (eg as return results from wifi.scan()).

Make it attrtuple then :-)

Reworked and merged in 5aa311d, c3184ae and d8837ce.

It's called attrtuple and is enabled by MICROPY_PY_ATTRTUPLE.

FYI, here are the stats on ROM usage, all for Thumb2 arch.

Without namedtuple, attrtuple costs 208 bytes of ROM.

With namedtuple, attrtuple costs 120 bytes of ROM (due to shared print function).

A new namedtuple type costs 16+N words, where N=number of fields in the tuple. Making an instance costs 2+N words.

A new attrtuple "type" costs N words (an array of qstrs). Making an instance costs 3+N words.

If you make M instances of a given tuple then the difference between namedtuple and attrtuple is 16-M words. That means if you make only 1 instance you save 15 words by using attrtuple. But if you make 16 or more instances it's better to use a namedtuple.

In the case of 1 instance (eg sys.implementation, os.uname()) you save 15 words = 60 bytes ROM by using attrtuple. So if you use attrtuple two times then it exactly breaks even (since savings = 2*60 = 120 = cost of attrtuple code).

Summary: attrtuple is worth it. Use it.

Summary: attrtuple is worth it. Use it.

Yes sir ;-)