This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Author methane
Recipients JelleZijlstra, eric.smith, methane, ncoghlan, pitrou, rhettinger, serhiy.storchaka, vstinner, xiang.zhang
Date 2017-07-17.13:30:28
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <1500298228.35.0.794538495214.issue28638@psf.upfronthosting.co.za>
In-reply-to
Content
I respect Raymond's rejection.  But I want to write down why I like Jelle's approach.

Currently, functools is the only module which is very popular.
But leaving this means every new namedtuple makes startup time about 0.6ms slower.

This is also problem for applications heavily depending on namedtuple.
Creating namedtuple is more than 15 times slower than normal class. It's not predictable or reasonable overhead.
It's not once I profiled application startup time and found namedtuple
account non-negligible percentage.

It's possible to keep `_source` with Jelle's approach. `_source` can be equivalent source rather than exact source eval()ed.
I admit it's not ideal. But all namedtuple user
and all Python implementation can benefit from it.

It's possible to expose StructSeq somewhere.  It can make it faster to
import `functools`.
But it's ugly too that applications and libraries tries it first
and falls back to namedtuple.
And when it is used widely, other Python implementations will be forced
to implement it.

That's why I'm willing collections.namedtuple overhead is reasonable and predictable.
History
Date User Action Args
2017-07-17 13:30:28methanesetrecipients: + methane, rhettinger, ncoghlan, pitrou, vstinner, eric.smith, serhiy.storchaka, xiang.zhang, JelleZijlstra
2017-07-17 13:30:28methanesetmessageid: <1500298228.35.0.794538495214.issue28638@psf.upfronthosting.co.za>
2017-07-17 13:30:28methanelinkissue28638 messages
2017-07-17 13:30:28methanecreate