[issue31230] Add __code__ attributes to generator and coroutine objects
Changes by syncosmic : -- pull_requests: +3163 ___ Python tracker <http://bugs.python.org/issue31230> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue31230] Add __code__ attributes to generator and coroutine objects
Changes by syncosmic : -- nosy: +syncosmic ___ Python tracker <http://bugs.python.org/issue31230> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue31230] Add __code__ attributes to generator and coroutine objects
Changes by syncosmic : -- pull_requests: -3163 ___ Python tracker <http://bugs.python.org/issue31230> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue31230] Add __code__ attributes to generator and coroutine objects
syncosmic added the comment: Some possibly helpful background (adapted from a discussion in PR 3077): It looks as though `gi_code` was added to generators in bpo-1473257. At this time, function bytecode was still stored in `f.func_code`, so `gi_code` was a clear analogy. My best guess is that `gi_code` was not chosen to deliberately create a namespace difference between functions and generators, but just because it wouldn't have made sense to add a `func_code` attribute to generators. In other words, if functions had had `code_object` instead of `func_code` at the time, bpo-1473257 might well have proposed `code_object` for generators. This doesn't, of course, mean that there might not be some post hoc reason to distinguish this part of the namespace now. Then `func_code` was changed in 3.0 to `__code__` as part of the `f.func_X` to `f.__X__` renaming. The 3.0 whatsnew explained that the purpose of this change was to "free up [the f.func_X] names in the function attribute namespace for user-defined attributes". But this wasn't done for the analogous code object in generators. On a quick look, I didn't find any discussion of this at the time, but that doesn't mean there wasn't any. -- ___ Python tracker <http://bugs.python.org/issue31230> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue31230] Add __code__ attributes to generator and coroutine objects
syncosmic added the comment: A related issue (since this issue is contemplating restructuring these objects anyway): Other than `??_code`, none of the `f.func_X` attributes which were eliminated in 3.0 have direct equivalents in generator-iterators, coroutines, or async generator-iterators. However, all three of those have `[gi|cr|ag]_running` and `[gi|cr|ag]_frame` attributes. Generator-iterators also have `gi_yieldfrom`, and coroutines and async generator-iterators have `[cr|ag]_await`. On a clean slate (with no attention paid to issues around breaking changes or how these attributes are already used in existing code), is there an argument for dundering some or all of these along with `__code__`? Or is special casing a better pattern when dealing with these other attributes? -- ___ Python tracker <http://bugs.python.org/issue31230> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue31230] Define a general "asynchronous operation introspection" protocol
syncosmic added the comment: I like where this is heading! Aside from the cleaner patterns for handling these objects, I think it'll make it a little easier for people who are just starting to use asynchronous objects in Python (e.g. me) to grasp what's similar about them. +1 that `__async_call__` could be confusing, for the general reason you mention, but in particular because it would look exactly analogous to `function.__call__()` (what the French call a "faux ami"). A not-thought-out alternative: what about noun-ing the verbs into `__async_calls__` and `__async_returns__` (or maybe `__async_returns_to__`)? BTW, I was thinking of taking a quick run at bpo-31197 while this simmers. I don't /think/ that risks being eventually mooted by these changes; if anything, it might be easier to adapt `dis` to this proposal if that refactoring has already been done. LMK if you think that's the wrong order, though. -- ___ Python tracker <http://bugs.python.org/issue31230> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
