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 _______________________________________