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 serhiy.storchaka
Recipients belopolsky, berker.peksag, bmispelon, corona10, p-ganssle, rhettinger, serhiy.storchaka, taleinat, tim.peters, vstinner
Date 2019-09-13.07:57:27
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <>
namedtuple is much faster now that four years ago. New namedtuple type creation, instantiating a namedtuple object, access to its members -- all this is times faster. It is still slower than tuple in some aspects, because tuples are everywere and the interpreter has special optimizations for tuples. But date.isocalendar() is not used in such performance critical code.

The size of pickles will grow, the time of pickling and unpickling will increase, and old Python versions will not be able to unpickle a new type by default. But I do not think that instances of this type will be pickled in large numbers so it will has a global effect, and the problem with compatibility can be solved with some hacks. If anybody pickles them at all.

It was not clear whether adding a new type will give any benefit in real code. Thanks to Paul for his investigations.

The only thing that makes this case unique is that we have two implementations of the datetime module. Therefore we will need either add two implementation of a new named tuple type (which are different in details) or import the Python implementation into the C code. This increases the cost of the implementation and maintaining.
Date User Action Args
2019-09-13 07:57:27serhiy.storchakasetrecipients: + serhiy.storchaka, tim.peters, rhettinger, belopolsky, vstinner, taleinat, berker.peksag, bmispelon, p-ganssle, corona10
2019-09-13 07:57:27serhiy.storchakasetmessageid: <>
2019-09-13 07:57:27serhiy.storchakalinkissue24416 messages
2019-09-13 07:57:27serhiy.storchakacreate