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 _______________________________________

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 _______________________________________

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 _______________________________________

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 _______________________________________

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 _______________________________________

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 _______________________________________

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 Michael Dorman mjdorma@gmail.com:

---------- nosy: +mjdorma

_______________________________________ 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 _______________________________________

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 _______________________________________

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 _______________________________________