[Python-Dev] PEP 454 - tracemalloc - accepted

Nick Coghlan ncoghlan at gmail.com
Fri Nov 22 00:17:14 CET 2013


On 22 Nov 2013 09:02, "Victor Stinner" <victor.stinner at gmail.com> wrote:
>
> 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.

namedtuple deviates from normal naming conventions to avoid name clashes
between field names and the attributes and methods of the object itself
(this is covered in the docs for namedtuple).

Skipping saving _source under -OO would probably be a good thing, but
otherwise it's a public API with the usual backwards compatibility
guarantees.

Cheers,
Nick.

>
> 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-dev/attachments/20131122/3cf8cb0a/attachment.html>


More information about the Python-Dev mailing list