make __closure__ writable
Can we make the __closure__ attribute writeable? Since __code__ already is, and it is possible to tackle with the opcodes, having no way of rewriting __closure__ (except creating a completely new function) is annoying. I don't think it will somehow harm python, as those who want to break it can do it already in multiple ways, easier than playing with __closure__. - Yury
On 16 March 2012 14:57, Yury Selivanov <yselivanov.ml@gmail.com> wrote:
Can we make the __closure__ attribute writeable? Since __code__ already is, and it is possible to tackle with the opcodes, having no way of rewriting __closure__ (except creating a completely new function) is annoying.
I don't think it will somehow harm python, as those who want to break it can do it already in multiple ways, easier than playing with __closure__.
+1 This could lead to "flatter" code in a lot of places, where the only way to have the code behave in certain ways is to write nested functions and class declarations.
- Yury
Yury Selivanov wrote:
Can we make the __closure__ attribute writeable? Since __code__ already is, and it is possible to tackle with the opcodes, having no way of rewriting __closure__ (except creating a completely new function) is annoying.
What's wrong with using a decorator?
I don't think it will somehow harm python, as those who want to break it can do it already in multiple ways, easier than playing with __closure__.
- Yury _______________________________________________ Python-ideas mailing list Python-ideas@python.org http://mail.python.org/mailman/listinfo/python-ideas
Decorators can be nested, and what you can do in this case is to find the most inner-wrapped function by traversing the '__wrapped__' attributes (and check that the function you found is the actual original function). After that you can play with its attributes, but you can't simply substitute the function object, as the inner decorator won't use it. So sometimes you have to work with the function object without a way of substituting it. - Yury On 2012-03-16, at 2:37 PM, Mark Shannon wrote:
Yury Selivanov wrote:
Can we make the __closure__ attribute writeable? Since __code__ already is, and it is possible to tackle with the opcodes, having no way of rewriting __closure__ (except creating a completely new function) is annoying.
What's wrong with using a decorator?
I don't think it will somehow harm python, as those who want to break it can do it already in multiple ways, easier than playing with __closure__. - Yury _______________________________________________ Python-ideas mailing list Python-ideas@python.org http://mail.python.org/mailman/listinfo/python-ideas
_______________________________________________ Python-ideas mailing list Python-ideas@python.org http://mail.python.org/mailman/listinfo/python-ideas
On Fri, Mar 16, 2012 at 1:57 PM, Yury Selivanov <yselivanov.ml@gmail.com> wrote:
Can we make the __closure__ attribute writeable? Since __code__ already is, and it is possible to tackle with the opcodes, having no way of rewriting __closure__ (except creating a completely new function) is annoying.
I don't think it will somehow harm python, as those who want to break it can do it already in multiple ways, easier than playing with __closure__.
- Yury
+1000, this would make code like https://github.com/magcius/toenail/blob/master/ailment.py#L20 much cleaner and more readable. Mike
On 2012-03-25, at 8:32 PM, Victor Stinner wrote:
2012/3/16 Yury Selivanov <yselivanov.ml@gmail.com>:
Can we make the __closure__ attribute writeable? Since __code__ already is, ...
I never understood why __code__ is writable. What is the usecase of modifying the code of an existing function?
Metaprogramming in its various forms. Read this thread and you'll find one use case. - Yury
On 26 March 2012 11:32, Victor Stinner <victor.stinner@gmail.com> wrote:
2012/3/16 Yury Selivanov <yselivanov.ml@gmail.com>:
Can we make the __closure__ attribute writeable? Since __code__ already is, ...
I never understood why __code__ is writable. What is the usecase of modifying the code of an existing function?
There are many things you can do with bytecode manipulation (whether you should is another question). Among other things, I've used it for optimisation (e.g. my optimised self.super recipe that probably isn't actually available online anymore). Instrumentation of code is another thing, although these days you're probably better off using a decorator. There aren't a lot of real use cases, but if nothing else it can be a lot of fun :) Tim Delaney
Tim Delaney wrote:
On 26 March 2012 11:32, Victor Stinner <victor.stinner@gmail.com <mailto:victor.stinner@gmail.com>> wrote:
2012/3/16 Yury Selivanov <yselivanov.ml@gmail.com <mailto:yselivanov.ml@gmail.com>>: > Can we make the __closure__ attribute writeable? Since __code__ already is, ...
I never understood why __code__ is writable. What is the usecase of modifying the code of an existing function?
There are many things you can do with bytecode manipulation (whether you should is another question). Among other things, I've used it for optimisation (e.g. my optimised self.super recipe that probably isn't actually available online anymore). Instrumentation of code is another thing, although these days you're probably better off using a decorator.
There aren't a lot of real use cases, but if nothing else it can be a lot of fun :)
You can do all of those things without changing the __code__ attribute. Just create a new function instead. Cheers, Mark
On 29 March 2012 19:05, Mark Shannon <mark@hotpy.org> wrote:
Tim Delaney wrote:
There are many things you can do with bytecode manipulation (whether you should is another question). Among other things, I've used it for optimisation (e.g. my optimised self.super recipe that probably isn't actually available online anymore). Instrumentation of code is another thing, although these days you're probably better off using a decorator.
There aren't a lot of real use cases, but if nothing else it can be a lot of fun :)
You can do all of those things without changing the __code__ attribute. Just create a new function instead.
Not if you want anything that holds an existing reference to the function to get the new behaviour. Sometimes you need to change things in-place. Tim Delaney
participants (6)
-
Joao S. O. Bueno -
Mark Shannon -
Mike Graham -
Tim Delaney -
Victor Stinner -
Yury Selivanov