New submission from Serhiy Storchaka storchaka@gmail.com:
__sizeof__ is not mentioned on page Doc/reference/datamodel.rst together with other special methods. There is no __sizeof__ in index.
assignee: docs@python components: Documentation messages: 166245 nosy: docs@python, storchaka priority: normal severity: normal status: open title: __sizeof__ is not documeneted versions: Python 2.7, Python 3.2, Python 3.3
Python tracker report@bugs.python.org http://bugs.python.org/issue15436
Changes by Serhiy Storchaka storchaka@gmail.com:
title: __sizeof__ is not documeneted -> __sizeof__ is not documented
Python tracker report@bugs.python.org http://bugs.python.org/issue15436
Jesús Cea Avión jcea@jcea.es added the comment:
Could you possibly write a patch for 2.7, 3.2 and 3.3?
nosy: +jcea
Python tracker report@bugs.python.org http://bugs.python.org/issue15436
Serhiy Storchaka storchaka@gmail.com added the comment:
Could you possibly write a patch for 2.7, 3.2 and 3.3?
No, not for documentation.
Python tracker report@bugs.python.org http://bugs.python.org/issue15436
Eric Snow ericsnowcurrently@gmail.com added the comment:
is __sizeof__ part of the language or just an implementation detail?
nosy: +eric.snow
Python tracker report@bugs.python.org http://bugs.python.org/issue15436
Serhiy Storchaka storchaka@gmail.com added the comment:
See issue2898.
Python tracker report@bugs.python.org http://bugs.python.org/issue15436
Meador Inge meadori@gmail.com added the comment:
It is part of runtime services and is mentioned in the documentation for 'sys.getsizeof' [1]:
""" getsizeof() calls the object’s __sizeof__ method and adds an additional garbage collector overhead if the object is managed by the garbage collector. """
[1] http://docs.python.org/library/sys.html?highlight=__sizeof__#sys.getsizeof.
nosy: +meador.inge
Python tracker report@bugs.python.org http://bugs.python.org/issue15436
Serhiy Storchaka storchaka@gmail.com added the comment:
It is part of runtime services and is mentioned in the documentation for 'sys.getsizeof' [1]:
Yes, but it is not mentioned in the index.
Python tracker report@bugs.python.org http://bugs.python.org/issue15436
Eric Snow ericsnowcurrently@gmail.com added the comment:
issue2898 smells like an implementation detail to me. Also, sys.getsizeof() isn't necessarily authoritative here, since the sys module is full of all sorts of implementation details.
I'm not saying __sizeof__ shouldn't be made an official part of the language, but we should be careful before we effectively etch something in stone for all Python implementations. It may be worth getting feedback from python-dev, particularly from the major Python implementers.
Python tracker report@bugs.python.org http://bugs.python.org/issue15436
Raymond Hettinger raymond.hettinger@gmail.com added the comment:
This may be CPython specific.
Also, sys.getsizeof() hasn't proved to be very useful (I never see anyone use it or see it in production code). Worse, it doesn't even make sense in the case of shared-key dictionaries and whatnot. Accordingly, there is little reason to make this more public than it already is. I would be happy to see it written-off as an implementation detail.
nosy: +rhettinger
Python tracker report@bugs.python.org http://bugs.python.org/issue15436
Antoine Pitrou pitrou@free.fr added the comment:
sys.getsizeof() is not for production code, it's for experimenting and getting information at the command prompt. It's quite useful when you know its limitations.
I'd argue that implementing __sizeof__ for user types doesn't make much sense (except C extension types, which are CPython-specific).
nosy: +pitrou
Python tracker report@bugs.python.org http://bugs.python.org/issue15436
Changes by Chris Rebert pybugs@rebertia.com:
nosy: +cvrebert
Python tracker report@bugs.python.org http://bugs.python.org/issue15436
Martin v. Löwis added the comment:
rhettinger: users frequently need sys.getsizeof. See, for example,
http://stackoverflow.com/questions/1331471/in-memory-size-of-python-stucture http://stackoverflow.com/questions/449560/how-do-i-determine-the-size-of-an-... http://stackoverflow.com/questions/2117255/python-deep-getsizeof-list-with-c... http://stackoverflow.com/questions/11301295/measure-object-size-accurately-i... [and so on]
In what cases, do you think, it generates meaningless results? I find the results for the shared-keys dictionary quite meaningful and natural.
sys.getsizeof is certainly CPython-specific. However, __sizeof__ is not just an implementation detail of sys.getsizeof, just as __len__ is not an implementation detail of len(). Authors of extension types are supposed to implement it if object.__sizeof__ is incorrect.
nosy: +loewis
Python tracker report@bugs.python.org http://bugs.python.org/issue15436
Serhiy Storchaka added the comment:
sys.getsizeof is certainly CPython-specific. However, __sizeof__ is not just an implementation detail of sys.getsizeof, just as __len__ is not an implementation detail of len(). Authors of extension types are supposed to implement it if object.__sizeof__ is incorrect.
I think there is one difference between __len__ and __sizeof__. __sizeof__ should be overloaded only for C-implemented classes. IMHO, it is a part of C API.
Python tracker report@bugs.python.org http://bugs.python.org/issue15436
Martin v. Löwis added the comment:
I think there is one difference between __len__ and __sizeof__. __sizeof__ should be overloaded only for C-implemented classes. IMHO, it is a part of C API.
That is a reasonable point. So documenting it along with the type slots might be best.
Python tracker report@bugs.python.org http://bugs.python.org/issue15436
Changes by Aaron Iles aaron.iles@gmail.com:
nosy: +aliles
Python tracker report@bugs.python.org http://bugs.python.org/issue15436
Changes by Serhiy Storchaka storchaka@gmail.com:
stage: -> needs patch type: -> enhancement versions: +Python 3.4
Python tracker report@bugs.python.org http://bugs.python.org/issue15436
Changes by Stephen Tonkin sptonkin@outlook.com:
nosy: +sptonkin
Python tracker report@bugs.python.org http://bugs.python.org/issue15436
Changes by Michael Dorman mjdorma@gmail.com:
nosy: +mjdorma
Python tracker report@bugs.python.org http://bugs.python.org/issue15436
Changes by Serhiy Storchaka storchaka@gmail.com:
keywords: +easy
Python tracker report@bugs.python.org http://bugs.python.org/issue15436
Changes by Andrew Svetlov andrew.svetlov@gmail.com:
nosy: +asvetlov
Python tracker report@bugs.python.org http://bugs.python.org/issue15436
Change by Philip Dye philip.h.dye@phd-solutions.com:
nosy: +Philip Dye
Python tracker report@bugs.python.org https://bugs.python.org/issue15436
Ido Michael michael.ido@gmail.com added the comment:
I can add those changes if someone didn't take it already?
Ido
nosy: +Ido Michael
Python tracker report@bugs.python.org https://bugs.python.org/issue15436
Change by Ido Michael michael.ido@gmail.com:
nosy: -Ido Michael
Python tracker report@bugs.python.org https://bugs.python.org/issue15436
Raymond Hettinger raymond.hettinger@gmail.com added the comment:
I can add those changes if someone didn't take it already?
I think we've decided that this is an implementation specific detail.
resolution: -> not a bug stage: needs patch -> resolved status: open -> closed
Python tracker report@bugs.python.org https://bugs.python.org/issue15436
-
Aaron Iles -
Andrew Svetlov
-
Antoine Pitrou
-
Chris Rebert
-
Eric Snow
-
Ido Michael
-
Jesús Cea Avión
-
Martin v. Löwis
-
Meador Inge
-
Michael Dorman
-
Philip Dye
-
Raymond Hettinger
-
Serhiy Storchaka
-
Stephen Tonkin