add variable "__this_func__" inside all functions' locals
How a function refer itself? def f(): f() # fine... really??? consider these situations: 1) decorator @xxx def f():... # how can I access the wrapped version? 2) replace by other def f(): f() # call second!! a = T(f) # to call first def f():... 3) refactor: rename function # first version def f():f() ------------------- # second version, wrap it def f(): log(); try: # to avoid indent _f_impl() except... def _f_impl(): _f_impl() # hadnot we rename it! solution: # add __this_func__ class C: @xxxx def f(self): self.f() __class__.f(self) __this_func__(self)
Hi, On 1 March 2017 at 01:12, 语言破碎处 <mlet_it_bew@126.com> wrote:
I understand your question as the following: "Should functions be allowed to point to themselves/the as of construction time unbound variable in the function body, as they are not yet bound to a variable at construction time" I think they should be allowed, as only when the function is executed the variable lookups (and therefore function lookups) should happen. Object.function() would have, well, interesting behaviour if you were to pre-insert all function calls in the code: d = {'hello': 'world'} def f(): d.keys = lambda: {} print(d.keys()) would result in "['keys']" being printed, while you explicitly said that the keys method on variable d has to return an empty dict. I hope this helps you with your question. -Matthias
We need not care other functions, just the "current" one. Other functions are definitely out of our control. My last example distinguish 3 cases: self.f() # object/overloaded version __class__.f(self) # decorated version __this_func__(self) # prime version At 2017-03-01 09:30:56, "Matthias welp" <boekewurm@gmail.com> wrote:
If your decorator uses `functools.wraps` or `functools.update_wrapper` (it should, for lots of reasons, and many, perhaps most, third party wrappers do), then you can access the wrapped function as `decorated.__wrapped__`. See https://docs.python.org/3/library/functools.html#functools.update_wrapper
Hi, On 1 March 2017 at 01:12, 语言破碎处 <mlet_it_bew@126.com> wrote:
I understand your question as the following: "Should functions be allowed to point to themselves/the as of construction time unbound variable in the function body, as they are not yet bound to a variable at construction time" I think they should be allowed, as only when the function is executed the variable lookups (and therefore function lookups) should happen. Object.function() would have, well, interesting behaviour if you were to pre-insert all function calls in the code: d = {'hello': 'world'} def f(): d.keys = lambda: {} print(d.keys()) would result in "['keys']" being printed, while you explicitly said that the keys method on variable d has to return an empty dict. I hope this helps you with your question. -Matthias
We need not care other functions, just the "current" one. Other functions are definitely out of our control. My last example distinguish 3 cases: self.f() # object/overloaded version __class__.f(self) # decorated version __this_func__(self) # prime version At 2017-03-01 09:30:56, "Matthias welp" <boekewurm@gmail.com> wrote:
If your decorator uses `functools.wraps` or `functools.update_wrapper` (it should, for lots of reasons, and many, perhaps most, third party wrappers do), then you can access the wrapped function as `decorated.__wrapped__`. See https://docs.python.org/3/library/functools.html#functools.update_wrapper
participants (3)
-
Matthias welp -
Ryan Hiebert -
语言破碎处