itertools.fixlen

[lehmannro]

BPO	5034
Nosy	@rhettinger, @pitrou
Files	fixlen.patch: patch to trunk

^{Note: these values reflect the state of the issue at the time it was migrated and might not reflect the current state.}

Show more details

GitHub fields:

assignee = 'https://github.com/rhettinger'
closed_at = <Date 2009-01-27.05:15:45.502>
created_at = <Date 2009-01-22.18:18:41.025>
labels = ['type-feature', 'library']
title = 'itertools.fixlen'
updated_at = <Date 2009-01-27.05:15:45.501>
user = 'https://bugs.python.org/lehmannro'

bugs.python.org fields:

activity = <Date 2009-01-27.05:15:45.501>
actor = 'rhettinger'
assignee = 'rhettinger'
closed = True
closed_date = <Date 2009-01-27.05:15:45.502>
closer = 'rhettinger'
components = ['Library (Lib)']
creation = <Date 2009-01-22.18:18:41.025>
creator = 'lehmannro'
dependencies = []
files = ['12833']
hgrepos = []
issue_num = 5034
keywords = ['patch']
message_count = 5.0
messages = ['80372', '80378', '80383', '80418', '80483']
nosy_count = 3.0
nosy_names = ['rhettinger', 'pitrou', 'lehmannro']
pr_nums = []
priority = 'normal'
resolution = 'rejected'
stage = None
status = 'closed'
superseder = None
type = 'enhancement'
url = 'https://bugs.python.org/issue5034'
versions = ['Python 3.1', 'Python 2.7']

[lehmannro]

As raised recently on python-ideas [1]_, an itertools method fixing
iterators to a certain length might be handy (where fixing is either
cutting elements off or appending values).

I appended a patch implementing this feature in Python/C, unit tests and
documentation included.

.. [1] http://thread.gmane.org/gmane.comp.python.ideas/2472/focus=2479

[pitrou]

"Return an iterator fixing *iterable*\ 's length to *length* by either
cutting elements off or adding *value* to the iterable."

Rather than mixing both, it would be more flexible to have a separate
function for each IMO.
Cutting off is already be handled by islice() (isn't it?), and padding
should be done with a function called e.g. pad() or rpad().

[rhettinger]

Am taking this under advisement but am initially disinclined. It is not
a basic itertool since it can be composed from the others. Also, it's
use cases seem to be few. One challenge for the module is that adding
more tools makes the overall toolkit harder to use because the number of
choices is increased.

[lehmannro]

When I started writing this patch this was actually what I intended. But
having fixlen(range(3), 2) return 0 1 2 struck me as odd. Renaming
the function to pad would help there indeed.

It depends on which use case is more common: either fixing an iterator
to a certain length (slicing/padding applied as required) or obtaining
an iterator of *at least* some number of elements (padded as required)?

The thread on python-ideas suggests the latter while the example Python
code brought up there implements the former. OTOH the latter cannot be
composed *that easily* of other itertools but the former is more useful
for unpacking.

On a related note: what should happen if length is negative?
itertools.repeat just defaults to 0 in such cases but I am unsure how
applicable that is in this case.

[rhettinger]

Am still leaning towards rejecting this one based on:

• paucity of use cases
• non-atomicity (it can be built-out of existing tools)
• minimizing the number of tools in the toolkit
• not convinced that padded tuple unpacking is desirable