typing.Union does not support attribute assignment post gh-105511
#132139
Comments
Union variable does not allow attribute assignment anymoretyping.Union variable does not allow attribute assignment anymore
|
Was it designed to support custom attributes? is it a documented behavior? (I don't know so I'm just asking if this was deliberate) |
|
Yeah, don't do that. Setting arbitrary attributes on Union objects (or any other typing objects) was never supported and if you do that sort of thing, be prepared for your code to break. That said, we could allow setting arbitrary attributes again by adding a managed |
How much of a cost are we talking about? I think you mentioned something about the fact that unions' size is smaller (or was it larger?) but I can't find the issue (I think I read this yesterday somewhere). If we're only talking about a few bytes when it's not used, then why not. But if we're doubling the union sizes I think it's maybe not worth. Now, are there other projects for which this could be needed? if there is enough usage, and from large libraries, then maybe it's a possibility? By the way, for what reason do you actually need unions to support assignment? |
typing.Union variable does not allow attribute assignment anymoretyping.Union variable does not allow attribute assignment anymore post gh-105511
typing.Union variable does not allow attribute assignment anymore post gh-105511typing.Union variable does not allow attribute assignment post gh-105511
typing.Union variable does not allow attribute assignment post gh-105511typing.Union does not support attribute assignment post gh-105511
|
(Recategorizing as a feature request since we're talking about an implementation detail that was not expected to be used) |
I think you're thinking of #131933 (comment) |
|
Regarding size of union objects: In 3.13 and earlier, there were two kinds of unions. Both were 48 bytes: In addition, Though I think those are only materialized if you actually access the attribute? There's some magic involved. However, the dict has 7 entries, so (assuming 8-byte pointers) somewhere we need space for at least 7 * 8 = 56 bytes. In 3.14, both kinds of unions were unified. The object is 72 bytes: That's because relative to the earlier
I think it's another 8 bytes, so not much.
For what it's worth, if this was purely a feature request I'd probably reject it quickly. The only reason we still need to talk about it is that we're breaking compatibility, even if the behavior we're breaking was never meant to exist in the first place. |
In this case this seems okayish.
Ah I thought you were considering it as a full-fledged feature. My bad (so I'm reputting the bug+314 labels). If we were to reinstate this, do we actually want to document the behavior? I don't really like the fact that only typing.Union would be able to set attributes (AFAIU). So if I were to choose I would either do nothing or also allow other types to support attributes assignments (but I don't know if we should document this). |
I was thinking of #131933 (comment) but yeah this was rhe discussion I had in kind. Thanks! |
|
I think we should add this to the documentation/What's New (it is an observable change), but I don't think it's worth it to add a dict to Code attempting this is already brittle: it only worked for one of the two types of unions, and further required that the name was a dunder. >>> typing.Union[int, str].__spam__ = 1
>>> typing.Union[int, str].spam = 1
Traceback (most recent call last):
File "<...>", line 1, in <module>
typing.Union[int, str].spam = 1
^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "...\Lib\typing.py", line 1219, in __setattr__
setattr(self.__origin__, attr, val)
AttributeError: '_SpecialForm' object has no attribute 'spam'All dunders are explicitly reserved to the language, so I think we should close this as wontfix, and possibly consider mentioning it in the documentation. A |
|
Good point, I hadn't noticed that it worked only for dunders because of Another confusing aspect here is the union cache that existed on 3.13: I feel that's enough reason that we should not make any change. If you want to associate arbitrary metadata with a type, you can use |
…set `Union` attributes Explain in a bit more detail why we think this is an acceptable change to make without a deprecation period
…set `Union` attributes (python#132157)
Bug report
Bug description:
Before #105511,
typing.Unionis implemented in Python, and custom attributes can be assigned to aUnionvariable.However, after #105511,
typing.Unionis now implemented in C, and no attributes can be assigned to it. TheUnionTypedoes not allow subclassing; users cannot bypass this using subclassing.Repro:
./python -m pip install -v optree ./python -c 'import optree; optree.PyTree[int]'Source: https://github.com/metaopt/optree/blob/v0.15.0/optree/typing.py#L246-L254
cc @JelleZijlstra
CPython versions tested on:
CPython main branch
Operating systems tested on:
macOS
Linked PRs
Unionattributes #132157The text was updated successfully, but these errors were encountered: