[Python-ideas] Re: Make __class__ (and maybe other magic variables) visible to functions that was defined outside a class, but then rebound into a class?
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 like child().foo() - when the callee
function is named as a class method. Dynamically.
#2/3
Also thanks for the idea of super(type(self), self) - that works! Like this,
class base():
def foo(self) -> None:
print('Base!')
def placement(self) -> None:
super(type(self), self).foo()
class child(base):
def foo(self) -> None:
pass
foo = placement
child().foo()
But in a more complex case where the base class calls also calls super()
this way, it runs into an infinite recursion. Like:
|class base(): def foo(self) -> None: print('Base!') def
placement(self) -> None: super(type(self), self).foo() class
child(base): def foo(self) -> None: pass foo = placement class
child2(child): def foo(self) -> None: pass foo = placement
child2().foo()|
||
#3/3
I also found it interesting that there are different results from
rebinding a class method with a function defined outside the class, and
with a function defined inside the class. Version 1 and version 2
results in the same error message:
class base:
def foo(self) -> None:
print('Base!')
class child(base):
def foo(self) -> None:
super().foo()
class another(base):
foo = child.foo
another().foo()
Version 2:
class base:
def foo(self) -> None:
print('Base!')
class child(base):
def foo(self) -> None:
print('Child!')
def placement(self) -> None:
super().foo()
foo = placement
class another(base):
foo = child.foo
another().foo()
which all result in a mysterious
TypeError: super(type, obj): obj must be an instance or subtype of type
I guess there is an argument issue. Maybe foo() is called as a classmethod?
While this,
class base:
def foo(self) -> None:
print('Base!')
def placement(self) -> None:
super().foo()
class child(base):
def foo(self) -> None:
print('Child!')
foo = placement
class another(base):
foo = child.foo
another().foo()
Results in the familiar RuntimeError: super(): __class__ cell not found.
Thank you!
Yua
On 28/07/2021 11:29, Christopher Barker wrote:
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 experiment, try adding the placement method to a different class
altogether and see what you get.
class another:
foo = child.placement
-CHB
On Tue, Jul 27, 2021 at 8:16 PM Yua > wrote:
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
child().foo()
RuntimeError: super(): __class__ cell not found
However, it would be OK if `placement` is defined inside the class:
class base():
def foo(self) -> None:
print('Base!')
class child(base):
def placement(self) -> None:
super().foo()
def foo(self) -> None:
pass
foo = placement
child().foo()
which prints:
Base!
I think it would be natural if those functions that was defined
outside
a class, but then rebound into a class, can see magic variables like
__class__ that are only shared by those functions defined inside a
class.
Thank you!
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
[Python-ideas] Re: Make __class__ (and maybe other magic variables) visible to functions that was defined outside a class, but then rebound into a class?
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 experiment, try adding the placement method to a different class
altogether and see what you get.
class another:
foo = child.placement
-CHB
On Tue, Jul 27, 2021 at 8:16 PM Yua wrote:
> 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
>
> child().foo()
>
> RuntimeError: super(): __class__ cell not found
>
>
> However, it would be OK if `placement` is defined inside the class:
>
> class base():
> def foo(self) -> None:
> print('Base!')
>
> class child(base):
> def placement(self) -> None:
> super().foo()
> def foo(self) -> None:
> pass
> foo = placement
>
> child().foo()
>
> which prints:
>
> Base!
>
>
> I think it would be natural if those functions that was defined outside
> a class, but then rebound into a class, can see magic variables like
> __class__ that are only shared by those functions defined inside a class.
>
>
> Thank you!
>
>
> ___
> Python-ideas mailing list -- python-ideas@python.org
> To unsubscribe send an email to python-ideas-le...@python.org
> https://mail.python.org/mailman3/lists/python-ideas.python.org/
> Message archived at
> https://mail.python.org/archives/list/python-ideas@python.org/message/GTTD2CSWNCSH2UW657YK3M7GPSUOKWYS/
> Code of Conduct: http://python.org/psf/codeofconduct/
>
--
Christopher Barker, PhD (Chris)
Python Language Consulting
- Teaching
- Scientific Software Development
- Desktop GUI and Web Development
- wxPython, numpy, scipy, Cython
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at
https://mail.python.org/archives/list/python-ideas@python.org/message/GQECYAN364AF2LGDU2O34ZE6PXLIRUBN/
Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Make __class__ (and maybe other magic variables) visible to functions that was defined outside a class, but then rebound into a class?
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
child().foo()
RuntimeError: super(): __class__ cell not found
However, it would be OK if `placement` is defined inside the class:
class base():
def foo(self) -> None:
print('Base!')
class child(base):
def placement(self) -> None:
super().foo()
def foo(self) -> None:
pass
foo = placement
child().foo()
which prints:
Base!
I think it would be natural if those functions that was defined outside
a class, but then rebound into a class, can see magic variables like
__class__ that are only shared by those functions defined inside a class.
Thank you!
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at
https://mail.python.org/archives/list/python-ideas@python.org/message/GTTD2CSWNCSH2UW657YK3M7GPSUOKWYS/
Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] More natural type hints for built-in containers
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 function(param1: {int: str} = {1: "foo"}, param2: (int, ...) = (1, 2, 3))
-> (int, (str, ...)):
return 3, ("foo", "bar")
as equivalent to:
var1: dict[str, tuple[int, int]] = {"label": (1, 2)}
var2: set[str] = {"other_label"}
def function(param1: dict[int, str] = (1, "foo"), param2: tuple[int, ...] = (1,
2, 3)) -> tuple[int, tuple[str, ...]]:
return 3, ("foo", "bar")
I thought of posting something like this as a mypy feature suggestion, but I
suspect the language would need to modify the way type annotations are
interpreted for something like it to work (or maybe not?).
Basically, inside a type annotation, the objects created by (a, b), [a], {a:
b}, {a} would be reinterpreted as the same thing as constructing tuple[a, b],
dict[a, b], list[a], set[a].
I have found myself wanting to write things like this a couple of times, so I
think this overloaded usage of builtin containters is natural.
I actually feel it is so natural it must either have been proposed before (in
which case I would love to give the feature my +1) or there is some more or
less obvious flaw.
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at
https://mail.python.org/archives/list/python-ideas@python.org/message/SUYRV7DTKSNNFLXLR74GWNQ632WTBCDL/
Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: weakref.link: Keep A alive while B is alive (and/or update WeakKeyDictionary)
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 reduced to any existing primitive as far as I can tell. Such a change would need to happen within the Python engine itself. ___ Python-ideas mailing list -- python-ideas@python.org To unsubscribe send an email to python-ideas-le...@python.org https://mail.python.org/mailman3/lists/python-ideas.python.org/ Message archived at https://mail.python.org/archives/list/python-ideas@python.org/message/KJUFOKVTU2YY32CS6TCRAN3P3XLBCJ42/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: weakref.link: Keep A alive while B is alive (and/or update WeakKeyDictionary)
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 while object B is alive. This > > would be functionally similar to adding A as an attribute of B from > > the GC's perspective without making any assumptions about what > > attributes are available in B. Here's a really course example of how > > this might be used: > > > > Probably, the "stake holders" on this list are well aware. But, as far > as I understand, this is (or requires) an "Ephemeron": > > https://en.wikipedia.org/wiki/Ephemeron > > While I might be tempted to try/use it if Python had it (and was > available from C), I doubt that it actually matters in practice, for my > "use case". > > > The "use case", why I was curious about it is for multiple-dispatching > (to allow users to extend NumPy). > If you dispatch based on input types and the input type can be deleted, > the same problem arises: The (type specific) implementation is > expected to – and sometimes must – hold a strong reference to the input > types. Thus creating an unbreakable circle. > > (You can avoid this sometimes, but I don't think you can in general) > > An Ephemeron should be able to describe this correctly. I expect even a > situation like: > > func(A, B) -> (A, B, C) > > which can be deleted if either `A` or `B` is "almost collectable", but > must keep alive `C` if both `A` and `B` are alive. > > Cheers, > > Sebastian > > > > # Associate "extra_data" with "obj" where "extra_data" will lose its > > reference when "obj" is no longer reachable through strong refs. > > my_link = weakref.link(obj, extra_data) > > > > ... > > > > obj, extra_data = my_link() > > if obj is not None: > > do_something(obj, extra_data) > > > > > > This would also allow us to fix or create a new version of > > WeakKeyDictionary where values can have strong references back to > > their key without preventing their key from being reclaimed. This has > > been an issue for tensorflow in the past (see > > https://github.com/tensorflow/tensorflow/issues/42022) and is likely > > to be a subtle issue in many more libraries. Even the suggested use > > case in the docs "This can be especially useful with objects that > > override attribute accesses." is likely to be broken because of this > > issue. While I'd be weary of changing the semantics of an existing > > data structure it seems highly unlikely anything depends on this > > behavior since it makes WeakKeyDictionary degrade to behaving like a > > normal dictionary for that key. > > > > > > Notes: > > * Not attached to this specific approach or API > > * Mostly interesting in updating/creating new WeakKeyDictionary as > > mentioned > > ___ > > Python-ideas mailing list -- python-ideas@python.org > > To unsubscribe send an email to python-ideas-le...@python.org > > https://mail.python.org/mailman3/lists/python-ideas.python.org/ > > Message archived at > > > https://mail.python.org/archives/list/python-ideas@python.org/message/4KBLRV7QYS36NVJNKAJIDCFTH4DF5YSY/ > > Code of Conduct: http://python.org/psf/codeofconduct/ > > > > ___ > Python-ideas mailing list -- python-ideas@python.org > To unsubscribe send an email to python-ideas-le...@python.org > https://mail.python.org/mailman3/lists/python-ideas.python.org/ > Message archived at > https://mail.python.org/archives/list/python-ideas@python.org/message/7C7EVG5ALBP266T6FROR6L7IK4GULPIS/ > Code of Conduct: http://python.org/psf/codeofconduct/ > ___ Python-ideas mailing list -- python-ideas@python.org To unsubscribe send an email to python-ideas-le...@python.org https://mail.python.org/mailman3/lists/python-ideas.python.org/ Message archived at https://mail.python.org/archives/list/python-ideas@python.org/message/AOFYS2KTGVEZJ2WFY7BOEUZIK2QGMJKY/ Code of Conduct: http://python.org/psf/codeofconduct/
