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 eric.smith, methane, ncoghlan, rhettinger, serhiy.storchaka, xiang.zhang
Date 2016-12-03.10:37:52
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <>
Argument Clinic is used just for running the generating code and inlining the result. This is the simplest part of Argument Clinic and using it looks an overhead. Argument Clinic has other disadvantages:

* In any case you need a rule in Makefile, otherwise the generated code can became outdated.

* Generated code depends not just on the generator code, but on the code of the collections module.

* Even tiny change in the generating code, namedtuple implementation or Argument Clinic code could need regenerating generated code with different checksums.

My second idea, more general solution, was making namedtuple itself using external caching. This would add a benefit for all users of namedtuple without changing a user code or with minimal changes.

namedtuple itself can save a bytecode and a source in files (like Java creates additional .class files for internal classes) and use a bytecode if it is not outdated. Generalized import machinery could be used for supporting generated code in a sync.
Date User Action Args
2016-12-03 10:37:53serhiy.storchakasetrecipients: + serhiy.storchaka, rhettinger, ncoghlan, eric.smith, methane, xiang.zhang
2016-12-03 10:37:53serhiy.storchakasetmessageid: <>
2016-12-03 10:37:53serhiy.storchakalinkissue28638 messages
2016-12-03 10:37:52serhiy.storchakacreate