Yes, I'm saying you need a really long justification to explain why you want to break backwards compatibility solely for a speed increase.

For namedtuple instances, the leading underscore does *NOT* indicate a private attribute - it's just there to avoid colliding with field names.

Speed isn't everything, and it certainly isn't adequate justification for breaking public APIs that have been around for years.

Now, you can either escalate that argument to python-dev, and try to convince Guido to overrule Raymond on this point, *or* you can look at working out a Python level API to dynamically define PyStructSequence subclasses. That won't be entirely straightforward (as my recollection is that structseq is designed to build on static C structs), but if you're successful, it will give you something that should be faster than namedtuple in every way, not just at definition time.