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.
Created on 2007年12月18日 01:49 by KirkMcDonald, last changed 2022年04月11日 14:56 by admin. This issue is now closed.
| Files | ||||
|---|---|---|---|---|
| File name | Uploaded | Description | Edit | |
| itertools.group.patch | KirkMcDonald, 2007年12月18日 01:49 | |||
| Messages (2) | |||
|---|---|---|---|
| msg58716 - (view) | Author: Kirk McDonald (KirkMcDonald) | Date: 2007年12月18日 01:49 | |
One question which is asked with surprising frequency in #python is how to yield multiple objects at a time from an iterable object. That is, given [1, 2, 3, 4, 5, 6], get [(1, 2), (3, 4), (5, 6)]. The "grouper" function in the itertools recipes page provides one pattern for this. A similar function (which behaves differently when the length of the iterable is not evenly divisible by n) looks like this: def group(iterable, n=2): return itertools.izip(*(iter(iterable),)*n) This code is fairly opaque to the novice. It is ugly, and takes a bit of head-scratching to realize exactly what it is doing. Because this operation is asked for with some frequency, and because this general implementation is so ugly, I believe it belongs in the library. There is a related function which is asked for much less frequently, but which is a more general case of the group() function listed above. This other function has a third "step" argument. This argument controls how far each group is in advance of the previous group. For example: list(group([1, 2, 3, 4], n=2, step=1)) -> [(1, 2), (2, 3), (3, 4)] The original function is equivalent to this function when step is equal to n. Please find attached a patch with implementation, documentation, and tests. |
|||
| msg58724 - (view) | Author: Raymond Hettinger (rhettinger) * (Python committer) | Date: 2007年12月18日 07:14 | |
Sorry, I'm not interested in adding this to the module. Discussions to- date on the subject seem to show more interest in playing with grouper variants than in actual use cases. While the recipe given in the docs is somewhat opaque, it runs at C-speed (zero trips around the eval- loop) and it is encapsulated in a re-usable function. Writing this in C does nothing to improve the situation. Also, when people like to play with variants, there is no general agreement on useful requirements (like fill-in behavior or raising an exception on uneven length inputs). Trying to write option to meet all needs (n=2, step=1) makes the code more difficult to learn and use -- see several variants in Alex's Python Cookbook. Another issue is that we have to be very selective about adding tools to the module. Each addition makes the overall toolset harder to use -- it is better to have a good set of basic building blocks. |
|||
| History | |||
|---|---|---|---|
| Date | User | Action | Args |
| 2022年04月11日 14:56:29 | admin | set | github: 45984 |
| 2007年12月18日 07:14:14 | rhettinger | set | status: open -> closed resolution: rejected messages: + msg58724 components: + Extension Modules, - Library (Lib) nosy: + rhettinger |
| 2007年12月18日 01:49:19 | KirkMcDonald | create | |