How can I get own instance of generator in itself code
Hi Python Software Foundation! I have learned Python for 2 years, and I love this language very much. The structure and grammar are simple and beautiful. I used this language in most of my projects. Now, I learn to use generator. This architecture is very intelligent. It allows programmer can pause and resume function. I think that this feature is not supported in classic language as C++, Java, C#.. In my design, we use 1 generator in both tasks: invoke and callback when download one url. But I have a small problem when getting instance of generator. How can I get own instance of generator in itself code? detail pseudo code example: def invoke_callback(url): do something here self = get myself (invoke_callback generator) instance #how can we do as this line???? data = yield asynchronous_dowload(url, callback = self.next) do something with data How can we do as this code. How can I get self variable?. Does the language support this feature? I cannot find it in any document in python.org. So, I have to solve it by wrapper it in a list. def invoke_callback(url, wrapper): self = wrapper[0] data = yield asynchronous_dowload(url, callback = self.next) do something with data wrapper = [] instance = invoke_callback(url, wrapper) wrapper.append(instance) instance.next() The other way is sending instance to itself, and we invoke twice. def invoke_callback(url): self = yield data = yield asynchronous_dowload(url, callback = self.next) do something with data instance = invoke_callback(url) instance.next() #first instance.send(instance) #second But the code in both of ways is not nice. Can you add this feature in the next version of python??? Regards Namdn
Le 15/07/2012 08:18, Đinh Nho Nam a écrit :
Hi, Maybe you could achieve that by inspecting the stack frame, but this is generally not recommended. But taking a step back, I think that the primitive you are looking for is a more general coroutine. greenlet can do this, and gevent builds on it to add higher level async networking: http://greenlet.readthedocs.org/en/latest/index.html http://www.gevent.org/ Regards, -- Simon Sapin
On 07/15/2012 08:18 AM, Đinh Nho Nam wrote:
I think that this feature is not supported in classic language as C++, Java, C#..
C# and Mozillas non-standard JavaScript also support generators (maybe not called "generators") and the yield statement.
On Sat, Jul 14, 2012 at 11:18 PM, Đinh Nho Nam <namdn@socbay.com> wrote:
I would suggest creating a decorator for this: def self_decorator(f): @functools.wraps(f) def decorated(*args, **kwargs): return f(f, *args, **kwargs) @self_decorator def do_stuff(self, a, b, c): pass Should work for any kind of function. And C/C++ do support such functionality in the sense that you can keep state in between function invocations: // This will return 1 the first time it is called, 2, the next time and so on... int generator() { static int num = 0; num += 1; return num; } On a final note, this question more appropriate for python-list. python-ideas is for the discussion of ideas to change python itself. Alex
Yes, in my project, i define a decorator to call twice as I said. The code below: def asynchronous(gen_func): class _generator(object): def __init__(self, *args, **kwargs): self.__generator = gen_func(*args, **kwargs) self.__generator.next() self.__generator.send(self.__generator) #override generator method: __iter__, next, send, ... def __iter__(self): return self.__generator def next(self): return self.__generator.next() def send(self, arg): return self.__generator.send(arg) def close(): return self.__generator.close() def __repr__(self): return repr(self.__generator) return _generator @asynchronous def invoke_callback(url): code here and we only call is as function, not need call send or next method g = invoke_callback(url) But i think the code is still not nice, because any we have to define @asynchronous in any generator. ----- Original Message ----- From: "Alexandre Zani" <alexandre.zani@gmail.com> To: "Đinh Nho Nam" <namdn@socbay.com> Cc: python-ideas@python.org Sent: Sunday, July 15, 2012 10:58:10 PM Subject: Re: [Python-ideas] How can I get own instance of generator in itself code On Sat, Jul 14, 2012 at 11:18 PM, Đinh Nho Nam <namdn@socbay.com> wrote:
I would suggest creating a decorator for this: def self_decorator(f): @functools.wraps(f) def decorated(*args, **kwargs): return f(f, *args, **kwargs) @self_decorator def do_stuff(self, a, b, c): pass Should work for any kind of function. And C/C++ do support such functionality in the sense that you can keep state in between function invocations: // This will return 1 the first time it is called, 2, the next time and so on... int generator() { static int num = 0; num += 1; return num; } On a final note, this question more appropriate for python-list. python-ideas is for the discussion of ideas to change python itself. Alex
On Sat, Jul 14, 2012 at 11:18 PM, Đinh Nho Nam <namdn@socbay.com> wrote:
Given that PEP 3130 (http://www.python.org/dev/peps/pep-3130/ ), which would have similarly added nice ways to get the current module, class, and regular function, was rejected, I wouldn't hold out much hope for such a feature being added any time soon. (Wrapping via decorators introduces nontrivial subtlety regarding whether you really want to refer to the decorated or undecorated version of an entity.) Cheers, Chris
The problem with PEP 3130 was the PEP itself, not the idea. I believe Eric Snow was working on a patch to implement this (see http://code.activestate.com/lists/python-ideas/11234/ and http://bugs.python.org/issue12857), but I'm not sure what its current status is. David On Jul 16, 2012 4:04 AM, "Chris Rebert" <pyideas@rebertia.com> wrote:
Yeah, this is still valuable. However, at this point it would be a 3.4 addition (_if_ it gets committed). Updating the patch in the tracker is on my todo for the next few months. -eric On Jul 16, 2012 1:13 AM, "David Townshend" <aquavitae69@gmail.com> wrote:
On Mon, Jul 16, 2012 at 10:28 AM, Eric Snow <ericsnowcurrently@gmail.com> wrote:
FWIW, the possibility of exposing something like __function__ in the function locals is less likely to garner support than the initial f_func approach. Said Guido[1]: <quote> If it were expected that people would start writing recursive calls using __function__ routinely, in situations where a name reference works, I'd be very unhappy with the new feature. (And if someone wants to make the argument that recursive calls using __function__ are actually better in some way I am willing to filibuster.) </quote> So there's a metric that f_func passes much more readily. That said, the f_func patch would also make "__function__" easier to implement if that feature passed muster. -eric [1] http://mail.python.org/pipermail/python-ideas/2011-August/011062.html
On Tue, Jul 24, 2012 at 10:59 AM, Eric Snow <ericsnowcurrently@gmail.com> wrote:
Python 3 already has an implicit lexical __class__ reference (courtesy of PEP 3135) and it refers to the inner *undecorated* version of the class. References by name, on the other hand, refer to the postdecorated version bound in the outer scope (which may or may not be the same object, depending on the specific decorators). A PEP for 3.4 that proposes a mechanism that more cleanly incorporates __class__ into the language data model (thus addressing http://bugs.python.org/issue12370) would be most welcome. Such a PEP could also attempt to make a symmetry argument for a __def__ reference that refers directly to the undecorated function object (as it's a lexical reference, it's worth emphasising the keyword over the kind of object). An implicit reference to the *decorated* object would not be acceptable, as decorators need to be able to call the function, even if it relies on the implicit reference. (This is the same reason why __class__ refers to the undecorated version: so that the class definition is complete while the decorator is running, which means they can instantiate it and call methods that use the new shorthand style super() invocation) The module self reference aspect discussed in PEP 3130 should just be dropped as using "mod = importlib.import_module(__name__)" is enough to avoid the odd behaviour associated with trying to use "__import__" directly. Cheers, Nick. -- Nick Coghlan | ncoghlan@gmail.com | Brisbane, Australia
On Mon, Jul 16, 2012 at 12:12 AM, David Townshend <aquavitae69@gmail.com> wrote:
Could you elaborate on how the PEP and the "idea" materially differed?
I would hardly describe mucking around with frame objects as "nice" (particularly compared against a dedicated keyword), so I would not say that it implements the same idea; though, to be sure, what the patch accomplishes is related, still useful, and could be used to power the implementation of something like the PEP. Belated regards, Chris -- Please avoid top-posting in the future :)
Could you elaborate on how the PEP and the "idea" materially differed?
IIRC, this was explained quite well in the thread I linked to. Basically the idea of accessing functions objects from within the function was fine, but the PEP didn't adequately answer all the questions it should have and tried to cover three ideas in one. To quote the rejection notice from the PEP: This PEP is rejected. It is not clear how it should be implemented or what the precise semantics should be in edge cases, and there aren't enough important use cases given. response has been lukewarm at best.
Agreed, but it is a good start.
Please avoid top-posting in the future :)
Sorry about that - tends to happen when I reply on my phone if I'm not concentrating.
Le 15/07/2012 08:18, Đinh Nho Nam a écrit :
Hi, Maybe you could achieve that by inspecting the stack frame, but this is generally not recommended. But taking a step back, I think that the primitive you are looking for is a more general coroutine. greenlet can do this, and gevent builds on it to add higher level async networking: http://greenlet.readthedocs.org/en/latest/index.html http://www.gevent.org/ Regards, -- Simon Sapin
On 07/15/2012 08:18 AM, Đinh Nho Nam wrote:
I think that this feature is not supported in classic language as C++, Java, C#..
C# and Mozillas non-standard JavaScript also support generators (maybe not called "generators") and the yield statement.
On Sat, Jul 14, 2012 at 11:18 PM, Đinh Nho Nam <namdn@socbay.com> wrote:
I would suggest creating a decorator for this: def self_decorator(f): @functools.wraps(f) def decorated(*args, **kwargs): return f(f, *args, **kwargs) @self_decorator def do_stuff(self, a, b, c): pass Should work for any kind of function. And C/C++ do support such functionality in the sense that you can keep state in between function invocations: // This will return 1 the first time it is called, 2, the next time and so on... int generator() { static int num = 0; num += 1; return num; } On a final note, this question more appropriate for python-list. python-ideas is for the discussion of ideas to change python itself. Alex
Yes, in my project, i define a decorator to call twice as I said. The code below: def asynchronous(gen_func): class _generator(object): def __init__(self, *args, **kwargs): self.__generator = gen_func(*args, **kwargs) self.__generator.next() self.__generator.send(self.__generator) #override generator method: __iter__, next, send, ... def __iter__(self): return self.__generator def next(self): return self.__generator.next() def send(self, arg): return self.__generator.send(arg) def close(): return self.__generator.close() def __repr__(self): return repr(self.__generator) return _generator @asynchronous def invoke_callback(url): code here and we only call is as function, not need call send or next method g = invoke_callback(url) But i think the code is still not nice, because any we have to define @asynchronous in any generator. ----- Original Message ----- From: "Alexandre Zani" <alexandre.zani@gmail.com> To: "Đinh Nho Nam" <namdn@socbay.com> Cc: python-ideas@python.org Sent: Sunday, July 15, 2012 10:58:10 PM Subject: Re: [Python-ideas] How can I get own instance of generator in itself code On Sat, Jul 14, 2012 at 11:18 PM, Đinh Nho Nam <namdn@socbay.com> wrote:
I would suggest creating a decorator for this: def self_decorator(f): @functools.wraps(f) def decorated(*args, **kwargs): return f(f, *args, **kwargs) @self_decorator def do_stuff(self, a, b, c): pass Should work for any kind of function. And C/C++ do support such functionality in the sense that you can keep state in between function invocations: // This will return 1 the first time it is called, 2, the next time and so on... int generator() { static int num = 0; num += 1; return num; } On a final note, this question more appropriate for python-list. python-ideas is for the discussion of ideas to change python itself. Alex
On Sat, Jul 14, 2012 at 11:18 PM, Đinh Nho Nam <namdn@socbay.com> wrote:
Given that PEP 3130 (http://www.python.org/dev/peps/pep-3130/ ), which would have similarly added nice ways to get the current module, class, and regular function, was rejected, I wouldn't hold out much hope for such a feature being added any time soon. (Wrapping via decorators introduces nontrivial subtlety regarding whether you really want to refer to the decorated or undecorated version of an entity.) Cheers, Chris
The problem with PEP 3130 was the PEP itself, not the idea. I believe Eric Snow was working on a patch to implement this (see http://code.activestate.com/lists/python-ideas/11234/ and http://bugs.python.org/issue12857), but I'm not sure what its current status is. David On Jul 16, 2012 4:04 AM, "Chris Rebert" <pyideas@rebertia.com> wrote:
Yeah, this is still valuable. However, at this point it would be a 3.4 addition (_if_ it gets committed). Updating the patch in the tracker is on my todo for the next few months. -eric On Jul 16, 2012 1:13 AM, "David Townshend" <aquavitae69@gmail.com> wrote:
On Mon, Jul 16, 2012 at 10:28 AM, Eric Snow <ericsnowcurrently@gmail.com> wrote:
FWIW, the possibility of exposing something like __function__ in the function locals is less likely to garner support than the initial f_func approach. Said Guido[1]: <quote> If it were expected that people would start writing recursive calls using __function__ routinely, in situations where a name reference works, I'd be very unhappy with the new feature. (And if someone wants to make the argument that recursive calls using __function__ are actually better in some way I am willing to filibuster.) </quote> So there's a metric that f_func passes much more readily. That said, the f_func patch would also make "__function__" easier to implement if that feature passed muster. -eric [1] http://mail.python.org/pipermail/python-ideas/2011-August/011062.html
On Tue, Jul 24, 2012 at 10:59 AM, Eric Snow <ericsnowcurrently@gmail.com> wrote:
Python 3 already has an implicit lexical __class__ reference (courtesy of PEP 3135) and it refers to the inner *undecorated* version of the class. References by name, on the other hand, refer to the postdecorated version bound in the outer scope (which may or may not be the same object, depending on the specific decorators). A PEP for 3.4 that proposes a mechanism that more cleanly incorporates __class__ into the language data model (thus addressing http://bugs.python.org/issue12370) would be most welcome. Such a PEP could also attempt to make a symmetry argument for a __def__ reference that refers directly to the undecorated function object (as it's a lexical reference, it's worth emphasising the keyword over the kind of object). An implicit reference to the *decorated* object would not be acceptable, as decorators need to be able to call the function, even if it relies on the implicit reference. (This is the same reason why __class__ refers to the undecorated version: so that the class definition is complete while the decorator is running, which means they can instantiate it and call methods that use the new shorthand style super() invocation) The module self reference aspect discussed in PEP 3130 should just be dropped as using "mod = importlib.import_module(__name__)" is enough to avoid the odd behaviour associated with trying to use "__import__" directly. Cheers, Nick. -- Nick Coghlan | ncoghlan@gmail.com | Brisbane, Australia
On Mon, Jul 16, 2012 at 12:12 AM, David Townshend <aquavitae69@gmail.com> wrote:
Could you elaborate on how the PEP and the "idea" materially differed?
I would hardly describe mucking around with frame objects as "nice" (particularly compared against a dedicated keyword), so I would not say that it implements the same idea; though, to be sure, what the patch accomplishes is related, still useful, and could be used to power the implementation of something like the PEP. Belated regards, Chris -- Please avoid top-posting in the future :)
Could you elaborate on how the PEP and the "idea" materially differed?
IIRC, this was explained quite well in the thread I linked to. Basically the idea of accessing functions objects from within the function was fine, but the PEP didn't adequately answer all the questions it should have and tried to cover three ideas in one. To quote the rejection notice from the PEP: This PEP is rejected. It is not clear how it should be implemented or what the precise semantics should be in edge cases, and there aren't enough important use cases given. response has been lukewarm at best.
Agreed, but it is a good start.
Please avoid top-posting in the future :)
Sorry about that - tends to happen when I reply on my phone if I'm not concentrating.
participants (8)
-
Alexandre Zani -
Chris Rebert -
David Townshend -
Eric Snow -
Mathias Panzenböck -
Nick Coghlan -
Simon Sapin -
Đinh Nho Nam