Re: [Python-ideas] Expose `itertools.count.start` and implement `itertools.count.__eq__` based on it, like `range`.
That would be great. 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)". Or, perhaps more simply, "range(x, None)" (so that no keyword arguments are needed).
2014-05-15 13:04 GMT-07:00 Ram Rachum <ram.r...@gmail.com <javascript:>>:
Now that I think about it, I would ideally want `itertools.count` to be deprecated in favor of `range(float('inf'))`, but I know that would never happen.
On Thursday, May 15, 2014 11:02:56 PM UTC+3, Ram Rachum wrote:
I suggest exposing `itertools.count.start` and implementing `itertools.count.__eq__` based on it. This'll provide the same benefits that `range` got by exposing `range.start` and allowing `range.__eq__`.
_______________________________________________ Python-ideas mailing list Python...@python.org <javascript:> https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/
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
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. Antony 2014-06-07 12:07 GMT-07:00 Terry Reedy <tjreedy@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@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/
On 8 Jun 2014 06:34, "Antony Lee" <antony.lee@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.
Antony
2014-06-07 12:07 GMT-07:00 Terry Reedy <tjreedy@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
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. 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@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/
_______________________________________________ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/
On 6/7/2014 4:33 PM, Antony Lee 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.
The issue is doing that with range, which is defined to a sequence, and is registered as a collections.abc.Sequence. Break the promise of that definition, break code, people scream. Many functions properly require a sequence rather than just any iterable. from collections.abc import Sequence def cross(seq): if not issubclass(seq, Sequence): raise TypeError("%x is not a collections.abc.Sequence" % type(seq)) for first in seq: for second in seq: yield (first, second) There is another issue with merely extending range -- its weird signature. Range(10) stops at 10; count(10) begins at 10. The signature of an iterable based on count should be based on count, not range. Semi-infinite-sequence could be a well-defined category of classes. But it should start outside of the stdlib. It could be fun, and have niche uses, like teaching. But like Nick, I am dubious that it would add enough to beyond having infinite iterators to warrant being in the stdlib. In any case, that would need to be proven with field experience. -- Terry Jan Reedy
participants (4)
-
Antony Lee -
Neil Girdhar -
Nick Coghlan -
Terry Reedy