Thank you for bringing that to my attention!
I think maybe can the interpreter decide whether __class__ etc. should
be added to the environment with regard to how the function is called?
The interpreter does not provide __class__ etc. for plain placement()
calls, but provide them at calls
How would the interpreter know which
Class the rebound “belonged” to?
For example, that same function could be added to two different classes—
then what would super() do?
BTW, the Python 2 style of calling súper with the class and instance as
arguments might work in the case :-)
As an
For example, the following code would report an error:
class base():
def foo(self) -> None:
print('Base!')
def placement(self) -> None:
super().foo()
class child(base):
def foo(self) -> None:
pass
foo = placement
Currently type hints for built-in containers are, in my opinion, less succint
than required. I suspect it is probably not very difficult for a type checker
to interpret something like this for example:
var1: {str: (int, int)} = {"label": (1, 2)}
var2: {str} = {"other_label"}
def
Looks like a separate issue to me. That issue can be fixed by updating the
Python implementation of WeakKeyDictioary.
The fix for the WeakKeyDictionary issue I mentioned and the Ephemeron primitive
(as Sebastian identified it) are equivalant (you can implement one from the
other) and cannot be
Would fixing this help? https://bugs.python.org/issue44140
On Tue, 20 Jul 2021, 02:16 Sebastian Berg,
wrote:
> On Mon, 2021-07-19 at 22:24 +, Mark Gordon wrote:
> > Proposal:
> >
> > Have a weakref.link (not at all attached to the naming) primitive
> > that allows one to keep object A alive
