Description

ronaldoussoren

opened on Feb 25, 2013

Issue body actions

BPO	17295
Nosy	@ronaldoussoren, @amauryfa, @vstinner, @vadmium
Superseder	bpo-1173475: slots for subclasses of variable length types

^{Note: these values reflect the state of the issue at the time it was migrated and might not reflect the current state.}

Show more details

GitHub fields:

assignee = None
closed_at = None
created_at = <Date 2013-02-25.16:24:22.254>
labels = ['interpreter-core', 'type-bug']
title = '__slots__ on PyVarObject subclass'
updated_at = <Date 2015-03-12.05:27:03.174>
user = 'https://github.com/ronaldoussoren'

bugs.python.org fields:

activity = <Date 2015-03-12.05:27:03.174>
actor = 'martin.panter'
assignee = 'none'
closed = False
closed_date = None
closer = None
components = ['Interpreter Core']
creation = <Date 2013-02-25.16:24:22.254>
creator = 'ronaldoussoren'
dependencies = []
files = []
hgrepos = []
issue_num = 17295
keywords = []
message_count = 5.0
messages = ['182959', '184637', '184640', '185397', '237914']
nosy_count = 4.0
nosy_names = ['ronaldoussoren', 'amaury.forgeotdarc', 'vstinner', 'martin.panter']
pr_nums = []
priority = 'low'
resolution = 'duplicate'
stage = 'resolved'
status = 'open'
superseder = '1173475'
type = 'behavior'
url = 'https://bugs.python.org/issue17295'
versions = ['Python 3.4']

Activity

1. ronaldoussoren commented on Feb 25, 2013

   

   ronaldoussoren

   on Feb 25, 2013

   ContributorAuthor

   More actions

   Currently a subclass of a PyVarObject (such as 'int') cannot use a non-empty slots, for example:

   >>> class L (int):
   ...    __slots__ = ('a', 'b')
   ... 
   Traceback (most recent call last):
     File "<stdin>", line 1, in <module>
   TypeError: nonempty __slots__ not supported for subtype of 'int'
   >>> 

   However, subclasses that don't use __slots__ do have an implicit slot: the __dict__ value. Wouldn't it be possible to use the trick used for tp_dictoffset for slots as well, that is use negative values for the slot offsets and access them from the end of the object?

   The major problem with an implementation is that PyMember_GetOne has a 'char*' argument instead of a 'PyObject*' one, but that's easily changed (PyMember_GetOne is currently only called in Object/descrobject.c and that call casts PyObject* to char*. This would be an API change, but AFAIK PyMember_GetOne is not documented at the moment (and changing the argument type would be binary compatible).

   I hope to work on a patch in the near future.
2. ronaldoussoren

   added

   interpreter-core(Objects, Python, Grammar, and Parser dirs)(Objects, Python, Grammar, and Parser dirs)

   on Feb 25, 2013
3. amauryfa commented on Mar 19, 2013

   

   amauryfa

   on Mar 19, 2013

   Contributor

   More actions

   Probably a duplicate of bpo-1173475. Do you want to work on the patch there?
4. ronaldoussoren commented on Mar 19, 2013

   

   ronaldoussoren

   on Mar 19, 2013

   ContributorAuthor

   More actions

   You're right, this is a duplicate.
5. ronaldoussoren

   added

   type-bugAn unexpected behavior, bug, or errorAn unexpected behavior, bug, or error

   on Mar 19, 2013
6. vstinner

   closed this as completedon Mar 28, 2013
7. vstinner commented on Mar 28, 2013

   

   vstinner

   on Mar 28, 2013

   Member

   More actions

   I closed the issue, but I didn't see that bpo-1173475 was closed. Sorry, I reopened this issue again.
8. vstinner

   reopened this on Mar 28, 2013
9. vadmium commented on Mar 12, 2015

   

   vadmium

   on Mar 12, 2015

   Member

   More actions

   Encountered this when trying to add some fields to urllib.parse.SplitResult for bpo-22852. bpo-1173475 has a patch; I haven’t tried using it though.
10. ezio-melotti

    transferred this issue fromon Apr 10, 2022
11. encukou commented on Apr 24, 2023

    

    encukou

    on Apr 24, 2023

    Member

    More actions

    For this to work, the interpreter must know the type's memory layout.
    So, in 2023 in Python 3.12 3.13, we can solve it for types with PEP 697's Py_TPFLAGS_ITEMS_AT_END, but for tuple or int we'd need to make their layout known (possibly we could hardcode it for those types only, but even then, documenting what kind of access is safe re. other types or subclasses might turn out to be a PEP-sized chunk of work).

    Let's use gh-103740 for enabling this with Py_TPFLAGS_ITEMS_AT_END.
12. erlend-aasland commented on Apr 24, 2023

    

    erlend-aasland

    on Apr 24, 2023

    Contributor

    More actions

    Let's use gh-103740 for enabling this with Py_TPFLAGS_ITEMS_AT_END.

    Let's close this as superseded by #103740, unless you have objections.
13. ronaldoussoren commented on Apr 24, 2023

    

    ronaldoussoren

    on Apr 24, 2023

    ContributorAuthor

    More actions

    Let's use gh-103740 for enabling this with Py_TPFLAGS_ITEMS_AT_END.

    Let's close this as superseded by #103740, unless you have objections.

    Fine by me.
14. erlend-aasland

    closed this as not plannedon Apr 24, 2023

Issue actions