[Python-Dev] PEP 454 - tracemalloc (original) (raw)
Victor Stinner victor.stinner at gmail.com
Fri Nov 22 00:02:02 CET 2013
- Previous message: [Python-Dev] PEP 454 - tracemalloc - accepted
- Next message: [Python-Dev] PEP 454 - tracemalloc - accepted
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
2013/11/21 Nick Coghlan <ncoghlan at gmail.com>:
Huzzah! Thanks to you both for getting this ready for inclusion :)
I now hope that someone will use it :-)
By the way, collections.namedtuple has a private _source attribute. This attributes uses something like 676.2 kB in the Python test suite, it the 5th biggest user of memory.
Woud you mind if I simply remove it?
I'm asking because this private attribute is documented, which is surprising for something private. I don't understand the use case. Is it to debug the implementation of the namedtuple? Or I imagined a different usecase: dump the _source into a file to speedup the startup time. But this optimization is not used in CPython whereas we care of the startup time.
Can maybe Raymond explain the use case for this attribute?
If there is a real use case, I would prefer a real function to get the source code of a function defining a new namedtuple type.
I already opened an issue for that: http://bugs.python.org/issue19640
--
The implementation of namedtuple constructor ("factory" ?) looks inefficient. Why do we need to build source code to then parse the code source? Why not having a base namedtuple class and then inherit from this class? It may reduce the memory footprint, allow to check if a type is namedtuple, etc.
There are two different concerns, I prefer to only focus on the removal of the _source attribute. But it's also to say the the _source attribute is very specific to the current (inefficient?) implement of the namedtuple constructor.
Victor
- Previous message: [Python-Dev] PEP 454 - tracemalloc - accepted
- Next message: [Python-Dev] PEP 454 - tracemalloc - accepted
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]