[issue34284] Nonsensical exception message when calling `__new__` on non-instaniable objects

Change by Irit Katriel : -- versions: +Python 3.11 -Python 3.8 ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue34284] Nonsensical exception message when calling `__new__` on non-instaniable objects

Vadim Pushtaev added the comment: Also for `curses.panel.panel`: >>> from curses.panel import panel >>> panel.__new__(panel) Traceback (most recent call last): File "", line 1, in TypeError: object.__new__(_curses_panel.panel) is not safe, use _curses_panel.panel.__new__() -- ___

[issue34284] Nonsensical exception message when calling `__new__` on non-instaniable objects

ppperry added the comment: Also happens for some objects in the `_tkinter` module: >>> _tkinter.TkttType.__new__(_tkinter.TkttType) Traceback (most recent call last): File "", line 1, in _tkinter.TkttType.__new__(_tkinter.TkttType) TypeError: object.__new__(_tkinter.tktimertoken) is not

[issue34284] Nonsensical exception message when calling `__new__` on non-instaniable objects

Vadim Pushtaev added the comment: Usually, tp_new==NULL means that __new__ is inherited, but not always. Here is the comment from typeobject.c: /* The condition below could use some explanation. It appears that tp_new is not inherited for static types whose base class is 'object'; this

[issue34284] Nonsensical exception message when calling `__new__` on non-instaniable objects

Serhiy Storchaka added the comment: Issue5322 may has a relation to this. -- ___ Python tracker ___ ___ Python-bugs-list mailing li

[issue34284] Nonsensical exception message when calling `__new__` on non-instaniable objects

Vadim Pushtaev added the comment: Sorry for the delay, I'm still working on a new PR. -- ___ Python tracker ___ ___ Python-bugs-lis

[issue34284] Nonsensical exception message when calling `__new__` on non-instaniable objects

Nick Coghlan added the comment: Agreed, but it's still a definition time bug, as the types are only nulling out tp_new after creating the singleton instance, and not preventing __new__ from resolving. If they *don't* null out tp_new, but instead set tp_new to a common helper function that r

[issue34284] Nonsensical exception message when calling `__new__` on non-instaniable objects

ppperry added the comment: The problem doesn't just happen with `sys.flags`, though. It happens with all types that can't be created directly by python. Ex: frame objects, generators, cells, etc. The bug is that in types whose c-level tp_new is null, the python-level __new__ is inherited fro

[issue34284] Nonsensical exception message when calling `__new__` on non-instaniable objects

Nick Coghlan added the comment: Looking at the code in https://github.com/python/cpython/blob/e42b705188271da108de42b55d9344642170aa2b/Python/sysmodule.c#L2360, I think the underlying problem here is that the code to make these PyStructSequence subclasses uninstantiable isn't really right -

[issue34284] Nonsensical exception message when calling `__new__` on non-instaniable objects

Vadim Pushtaev added the comment: > See also issue31506 Okay, I admit, reporting `tuple.__new__` instead of `sys.flags` is misleading. But what about this? > `tuple.__new__(NamedTuple)` works, and produces a namedtuple object, so > tuple.__new__ is what the error should point to. Isn't it

[issue34284] Nonsensical exception message when calling `__new__` on non-instaniable objects

Serhiy Storchaka added the comment: See also issue31506. -- nosy: +ncoghlan, serhiy.storchaka ___ Python tracker ___ ___ Python-bug

[issue34284] Nonsensical exception message when calling `__new__` on non-instaniable objects

ppperry added the comment: Thus, I think the bug is that "type(sys.flags).__new__" is an alias for "tuple.__new__" and is not in the code for __new__ calls that your PR touches. -- ___ Python tracker __

[issue34284] Nonsensical exception message when calling `__new__` on non-instaniable objects

ppperry added the comment: The error I'm expecting here is "cannot create sys.flags objects". Anything else violates the fact that type(*args) is sugar for: result = type.__new__(type, *args) if isinstance(result, type): result.__init__(*args) ("type" in the above snippet is a variable n