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 rhettinger
Recipients JelleZijlstra, eric.smith, methane, ncoghlan, rhettinger, serhiy.storchaka, xiang.zhang
Date 2017-07-17.00:54:06
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <>
> creates only one necessary backwards compatibility break 
> (we no longer have _source).

IMO, this is an essential feature.  It allows people to easily build their own variants, to divorce the generated code from the generator, and to fully understand what named tuples do (that is in part why we get so few questions about how they work).

You all seem to be in rush to redesign code that has been stable and well served the needs of users for a very long time.  This all seems to be driven by a relentless desire for micro-optimizations regardless of actual need.

BTW, none of the new contributors seem to be aware of named tuple's history.  It was an amalgamation of many separate implementations that had sprung up in the wild (it was being reinvented many times).  It was posted as ASPN recipe and went through a long period of maturation that incorporated the suggestions of over a dozen engineers based on use in the field.  It went through further refinement when examined and discussed on the pythoh-dev incorporating reviews from Guido, Alex, and Tim.  Since that time, the tools has been broadly deployed and met the needs of enormous numbers of users. Its use is considered a best practice.  The code and API have maintained and improved an intentionally slow and careful pace.

I really, really do not want to significantly revised the stable code and undermine the premise of its implementation so that you can save a few micro-seconds in the load of some module.  That is contrary to our optimization philosophy for CPython.  

As is, the code is very understandable, easy to maintain, easy to understand, easy to create variants, easy to verify that it is bug free. It works great for CPython, IronPython, PyPy, and Jython without modification.
Date User Action Args
2017-07-17 00:54:08rhettingersetrecipients: + rhettinger, ncoghlan, eric.smith, methane, serhiy.storchaka, xiang.zhang, JelleZijlstra
2017-07-17 00:54:08rhettingersetmessageid: <>
2017-07-17 00:54:08rhettingerlinkissue28638 messages
2017-07-17 00:54:06rhettingercreate