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 llllllllll
Recipients eric.smith, llllllllll
Date 2015-04-10.21:20:33
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <1428700833.48.0.300972992459.issue23910@psf.upfronthosting.co.za>
In-reply-to
Content
Ideally, namedtuple is used to make your code cleaner, using "magic" indecies is less clear than using a named index in a lot of cases. Because namedtuple is mainly to make the code more readable, I don't think that it should have an impact on the runtime performance of the code. This means that namedtuple should be a very thin wrapper around tuple. Currently, namedtuple named item access is much slower than elementwise access. I have this as a standalone package (there are some changes in the diff I posted to acheive full backwards compat) here https://pypi.python.org/pypi/cnamedtuple/0.1.5 that show some profiling runs of this code. The notable one to me is named item access being around twice as fast.

Another issue we ran into at work is that we found ways to get the exec call in nametuple to execute arbitrary code; while this would not be a concern for most people by the nature of the way we got this to happen, we wanted to look at other ways of writing namedtuple. I looked through some older discussion and found that non-exec solutions were rejected in the past for perfomance reasons.
History
Date User Action Args
2015-04-10 21:20:33llllllllllsetrecipients: + llllllllll, eric.smith
2015-04-10 21:20:33llllllllllsetmessageid: <1428700833.48.0.300972992459.issue23910@psf.upfronthosting.co.za>
2015-04-10 21:20:33lllllllllllinkissue23910 messages
2015-04-10 21:20:33llllllllllcreate