Carlos Damazio added the comment:
Opened a PR for this issue. It'll remove the mentions to the
`Py_USING_MEMORY_DEBUGGER` since it'd been removed 5 years ago.
--
nosy: +carlosdamazio
___
Python tracker
<https://bugs.python.o
Carlos Damazio added the comment:
I think I have a fix for this, I opened a PR. Let me know if you have any
questions.
--
nosy: +carlosdamazio
___
Python tracker
<https://bugs.python.org/issue46
Carlos Damazio added the comment:
Well, to this issue, I'm going to put a PR to remove it and give it a chance
for it to being reinstated if you folks want to.
--
nosy: +carlosdamazio -dmzz
___
Python tracker
<https://bugs.python.org/is
Carlos Damazio added the comment:
And here's the code to reproduce the bug in 3.10.
--
Added file: https://bugs.python.org/file50524/bug310.py
___
Python tracker
<https://bugs.python.org/i
Carlos Damazio added the comment:
This is the server for testing in 3.10.
--
nosy: +carlosdamazio
Added file: https://bugs.python.org/file50523/server310.py
___
Python tracker
<https://bugs.python.org/issue2
Carlos Damazio added the comment:
Josh: My mistake, I've seen a similar issue, then. And agreed, I think #2 is a
great candidate since we don't need to re-design existing structures. I don't
know a better option... yet.
--
___
Carlos Damazio added the comment:
Normally, users assume it's safe to use `super` without explicit arguments,
until an undefined behavior happens, such as now. The only thing that glances
into this issue is the observation in the docs you've provided that omitting
the second argu
Carlos Damazio added the comment:
By explicitly sending a type and object to the super function, it should work
as usual, like in the file that I've just sent. I've seen this behavior before,
it's related to Python's module reload function, which returns a new refere