[issue11628] cmp_to_key generated class should use __slots__
New submission from Chris Colbert :
The cmp_to_key func acts as a class factory for generating key objects that
behave according to a user defined cmp function.
Many patterns/libs that make use of key functions (for example blist and the
SortedCollection recipe) store the the results of the key function internally
to provide faster subsequent operations. For large datasets, the number of key
objects can become large, and it makes sense to keep their memory footprint as
small as possible.
>From this stance, I propose to add "__slots__ = ('obj',)" to the class
>definition of "K" in cmp_to_key to prevent the creation of the un-needed
>instance dict and save the memory.
I find it hard to conjure up a case where a user would need to weakref or add
attributes to the return value of a key func. But should that need arise, that
functionality could be provided as optional kwargs to cmp_to_key, or just have
the user subclass the return value of cmp_to_key. Alternatively, the addition
of __slots__ could be specified as a kwarg to cmp_to_key.
I'd be happy to make a patch for any of these (or alternative) options.
--
components: Library (Lib)
messages: 131691
nosy: Chris.Colbert, ncoghlan, rhettinger
priority: normal
severity: normal
status: open
title: cmp_to_key generated class should use __slots__
type: behavior
versions: Python 2.7, Python 3.1, Python 3.2, Python 3.3, Python 3.4
___
Python tracker
<http://bugs.python.org/issue11628>
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue11628] cmp_to_key generated class should use __slots__
Chris Colbert added the comment: Man, you guys are quick! Cheers! -- ___ Python tracker <http://bugs.python.org/issue11628> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue16272] C-API documentation clarification for tp_dictoffset
New submission from Chris Colbert: The documentation of the tp_dictoffset is a bit unclear when describing the responsibilities of a base type with a nonzero tp_dictoffset. http://docs.python.org/c-api/typeobj.html I feel there should some statement to the effect of: """ If a type defines a nonzero tp_dictoffset, that type is responsible for defining a `__dict__` slot as part of the tp_getset structures. Failure to do so will result in the dict being inaccesible from Python via `obj.__dict__` from instances of the type or subtypes. """ The reasoning is twofold: 1) `PyType_Ready` does not add the default getset members like `type_new` does. This prevents the instances of the type itself from retrieving `obj.__dict__` 2) `type_new` will provide the default `subtype_dict` getset member for subclasses, but this calls `get_builtin_base_with_dict` which will resolve to the most base type which is not heap allocated; in this case, the C type. Since this type has no `__dict__` getset member, the lookup fails. Adding a bit of verbage about this "gotcha" would likely save some headaches in the future. -- assignee: docs@python components: Documentation messages: 173222 nosy: Chris.Colbert, docs@python priority: normal severity: normal status: open title: C-API documentation clarification for tp_dictoffset versions: Python 2.6, Python 2.7, Python 3.1, Python 3.2, Python 3.3, Python 3.4, Python 3.5 ___ Python tracker <http://bugs.python.org/issue16272> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22453] PyObject_REPR macro causes refcount leak
New submission from Chris Colbert: This is how the macro is defined in object.h: 2.7 /* Helper for passing objects to printf and the like */ #define PyObject_REPR(obj) PyString_AS_STRING(PyObject_Repr(obj)) 3.4 /* Helper for passing objects to printf and the like */ #define PyObject_REPR(obj) _PyUnicode_AsString(PyObject_Repr(obj)) PyObject_Repr returns a new reference, which is not released by the macro. This macro only seems to be used internally for error reporting in compile.c, so it's unlikely to be causing any pressing issues for the interpreter, but it may be biting some extension modules. -- components: Extension Modules, Interpreter Core messages: 227219 nosy: Chris.Colbert priority: normal severity: normal status: open title: PyObject_REPR macro causes refcount leak type: behavior versions: Python 2.7, Python 3.1, Python 3.2, Python 3.3, Python 3.4, Python 3.5 ___ Python tracker <http://bugs.python.org/issue22453> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
