[Python-ideas] Expose `itertools.count.start` and implement `itertools.count.__eq__` based on it, like `range`.

Nick Coghlan ncoghlan at gmail.com
Sun Jun 8 01:10:19 CEST 2014


On 8 Jun 2014 06:34, "Antony Lee" <antony.lee at berkeley.edu> wrote:
>
> I agree that "range(start=x)" is awkward due to the unusual argument
handling of "range", and you are also correct that I should have said "an
iterable for which iter(range(x, None, step)) behaves as count(n, step)".
> I don't see an issue with len and negative indexing raising ValueError
and IndexError, respectively.  After all, a negative index on an infinite
sequence is just as undefined.

This is missing the point. We already have a better abstraction for data
sources of unknown (potentially infinite) length: the iterator protocol.

Yes we *could* define an infinite sequence as "like a sequence, but almost
all the operations that distinguish it from an iterator throw an
exception", but that's a long way from making a case for why we *should*.

Nobody in this thread has addressed key questions like the following:

* What is the actual use case for "infinite sequences"?
* How is the "infinite sequence" concept easier to teach, write & read than
existing approaches based on the itertools module?
* How does claiming to provide a particular interface, and then throwing
exceptions when you actually try to use it provide a better API user
experience than continuing with the status quo?

The bar for new syntax in Python is high, but the bar for new semantic
concepts is even higher.

Regards,
Nick.

> Antony
>
>
> 2014-06-07 12:07 GMT-07:00 Terry Reedy <tjreedy at udel.edu>:
>
>> On 6/6/2014 9:59 PM, Neil Girdhar wrote:
>>>
>>> That would be great.
>>
>>
>> What does 'that' refer too? Ram's original proposal, which you quoted,
or Antony's counter-proposal, which you also quoted? Ambiguity is the cost
of top-posting combined with over-quoting.
>>
>> Since I already explained what is wrong with Ram's proposal, I will
delete it and assume you mean Antony's, which seems to not have arrived on
my machine.
>>
>>
>>> On Friday, May 16, 2014 12:16:52 AM UTC-4, Antony Lee wrote:
>>>
>>>     Actually, a more reasonable solution would be to have range handle
>>>     keyword arguments and map "range(start=x)"  to "count(x)".
>>
>>
>> Having a parameter like 'start' mean two different things when passed by
position and name is the sort of oddity we try to avoid.
>>
>> Since "a range object is an immutable, constant attribute, reiterable
sequence object" (my earlier post), while count is an iterator, that does
not literally work. So I will assume that you mean (looking ahead) 'an
iterable sis_range such that iter(sis_range(n, None, step)) is the same as
count(n, step)'.
>>
>>
>>> Or,  perhaps more simply, "range(x, None)"
>>
>>
>> As an expression, stop=None is literally what you mean.
>>
>> The problem is that range is a finite sequence with a finite length and
an indexable end. For instance, range(10)[-1] == 9. What is needed is a new
semi_infinite_sequence base class 'SemiInfSeq' that allows (but not
requires) infinite length: float('inf') or a new int('inf'). It would also
have to disallow negative ints for indexing and slicing. Or perhaps a class
factory is needed.
>>
>> Many infinite iterators whose items can be calculated from index n could
be the iterator for a SIS subclass.  A geometric series and the sequence of
squares are other examples. This could be a PyPI package.
>>
>> --
>> Terry Jan Reedy
>>
>>
>> _______________________________________________
>> Python-ideas mailing list
>> Python-ideas at python.org
>> https://mail.python.org/mailman/listinfo/python-ideas
>> Code of Conduct: http://python.org/psf/codeofconduct/
>
>
>
> _______________________________________________
> Python-ideas mailing list
> Python-ideas at python.org
> https://mail.python.org/mailman/listinfo/python-ideas
> Code of Conduct: http://python.org/psf/codeofconduct/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-ideas/attachments/20140608/eec7100f/attachment.html>


More information about the Python-ideas mailing list