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 | gvanrossum |
|---|---|
| Recipients | belopolsky, georg.brandl, gvanrossum, rhettinger |
| Date | 2008年04月30日.17:22:33 |
| SpamBayes Score | 0.0012110888 |
| Marked as misclassified | No |
| Message-id | <1209576156.31.0.09939840154.issue2719@psf.upfronthosting.co.za> |
| In-reply-to |
| Content | |
|---|---|
Feel free to submit a patch to fix the docs. Changing the API is not an option -- it's been like this since the tp_iternext slot was added, and it's been designed like this for a reason: so that in the common case of iterating over a built-in sequence type no exception objects have to be created. In particular the for-loop code would just discard the StopIteration instance again. The requirement that the exception is *optional* is so that if you're calling a Python iterator that *does* create the exception, the exception object (with whatever data the creator might have attached to it) doesn't get lost (or worse, have to be recreated). Calling PyIter_Next() here instead of inlining it would not be advantageous; it would just slow things down since we'd have to make a redundant call to PyErr_Occurred() to distinguish the StopIteration case from other errors. |
|
| History | |||
|---|---|---|---|
| Date | User | Action | Args |
| 2008年04月30日 17:22:37 | gvanrossum | set | spambayes_score: 0.00121109 -> 0.0012110888 recipients: + gvanrossum, georg.brandl, rhettinger, belopolsky |
| 2008年04月30日 17:22:36 | gvanrossum | set | spambayes_score: 0.00121109 -> 0.00121109 messageid: <1209576156.31.0.09939840154.issue2719@psf.upfronthosting.co.za> |
| 2008年04月30日 17:22:35 | gvanrossum | link | issue2719 messages |
| 2008年04月30日 17:22:33 | gvanrossum | create | |