Message300471
| Author |
syncosmic |
| Recipients |
ncoghlan, syncosmic |
| Date |
2017年08月18日.02:52:31 |
| SpamBayes Score |
-1.0 |
| Marked as misclassified |
Yes |
| Message-id |
<1503024752.45.0.233655753029.issue31230@psf.upfronthosting.co.za> |
| In-reply-to |
| Content |
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. |
|
History
|
|---|
| Date |
User |
Action |
Args |
| 2017年08月18日 02:52:32 | syncosmic | set | recipients:
+ syncosmic, ncoghlan |
| 2017年08月18日 02:52:32 | syncosmic | set | messageid: <1503024752.45.0.233655753029.issue31230@psf.upfronthosting.co.za> |
| 2017年08月18日 02:52:32 | syncosmic | link | issue31230 messages |
| 2017年08月18日 02:52:31 | syncosmic | create |
|