This issue tracker has been migrated to GitHub ,
and is currently read-only.
For more information,
see the GitHub FAQs in the Python's Developer Guide.
| Author | ntoronto |
|---|---|
| Recipients | arkanes, christian.heimes, gvanrossum, ntoronto |
| Date | 2007年11月29日.23:27:26 |
| SpamBayes Score | 0.000491943 |
| Marked as misclassified | No |
| Message-id | <1196378846.57.0.458134550995.issue1518@psf.upfronthosting.co.za> |
| In-reply-to |
| Content | |
|---|---|
Christian: Thanks for that, I'll have to remember DEBUG_LEAK in the future. :) It looks like it may be acting correctly since there *is* now a fastglobals object that needs collecting, and also a new tuple built from co_names + "__builtins__". I don't know why it wouldn't collect those in the shell, though. The shell does create a new stack frame for every command (where a function's commands are all run in a single stack frame), but I don't know why that would matter. I'll look further into it. Chris: The build problems should be fixed in the next patch. Thanks for spending so much time on benchmarking this. Regarding PyEval_EvalCode creating a PyFastGlobalsObject: I'm not sure whether it's right thing to do, but I think it is. PyEval_EvalCode gets called for eval, exec, running an imported module's code, and everything in the interactive prompt - basically, running any code that's not in a function or generator. (I think that covers everything.) It seems like the patch has PyEval_EvalCode doing the right thing in general, but it may suffer a bit in benchmarks. |
|
| History | |||
|---|---|---|---|
| Date | User | Action | Args |
| 2007年11月29日 23:27:26 | ntoronto | set | spambayes_score: 0.000491943 -> 0.000491943 recipients: + ntoronto, gvanrossum, christian.heimes, arkanes |
| 2007年11月29日 23:27:26 | ntoronto | set | spambayes_score: 0.000491943 -> 0.000491943 messageid: <1196378846.57.0.458134550995.issue1518@psf.upfronthosting.co.za> |
| 2007年11月29日 23:27:26 | ntoronto | link | issue1518 messages |
| 2007年11月29日 23:27:26 | ntoronto | create | |