On Tue, Dec 10, 2019 at 1:37 AM Andrew Barnert wrote:
>
> On Dec 9, 2019, at 22:07, Wes Turner wrote:
> >
> >
> > Sets are not collections.abc.Sequence because they do not implement
> > __getitem__.
> > Are there other unordered Iterables in the standard library
>
> Again, it depends on what you
On Dec 9, 2019, at 22:07, Wes Turner wrote:
>
>
> Sets are not collections.abc.Sequence because they do not implement
> __getitem__.
> Are there other unordered Iterables in the standard library
Again, it depends on what you’re trying to distinguish by that word
“unordered”. Mappings (includi
def next(iterable[, default]):
"""
Returns:
Return the next item from the iterator.
Raises:
StopIteration: when iterator is empty and default is not specified
"""
def first(iterable, default=None):
"""
Returns:
default (which defaults to None) if the
[Guido]
> The argument that first(it) and next(it) "look the same" doesn't convince
> me;
I'm sorry - I guess then I have absolutely no idea what you were
trying to say, and read it completely wrong.
> if these look the same then all function applications look the same, and
> that can certainly n
Serhiy Storchaka wrote:
> Would not adding a recipe in the itertools documentation or the tutorial
> help?
I think adding a recipe in the itertools documentation might help, but I
don't know that it would be a great fit for the tutorial. It seems a bit
too specific and could be a distraction from
The argument that first(it) and next(it) "look the same" doesn't convince
me; if these look the same then all function applications look the same,
and that can certainly not have been Meertens' intention. But if everyone
thinks that first() should raise, fine, this thread is way too long already
(I
[Guido]
> ...
> Similarly, there is already a spelling of first() (or close enough) that
> raises: 1-arg next().
> If 1-arg first() would also raise, it would fail the rule "similar things
> should be spelled
> similarly, and different things should be spelled differently".
The "... unless you'r
On Mon, Dec 9, 2019 at 6:19 PM Juancarlo Añez wrote:
> I agree with others in that the "*default*" argument should be explicit
> instead of implied. It's how *dict.get()*, and *dict.pop()*, etc., work. The
> exceptions raised when nothing can be returned from *first()* and there
> is no *default=
On Dec 9, 2019, at 18:23, Juancarlo Añez wrote:
>
>
>> So while 1-arg next() and the try/except StopIteration pattern are essential
>> and well-known, 2-arg next() is relatively esoteric and consequently (I
>> think) not nearly as well-known.
>
> And knowing that you must use iter() for 2-ar
Juancarlo Añez writes:
> the_first_item_if_ordered = next(iter(container), default='not found')
Ouch!
> one_item_if_any = first(return_a_set(), default=-1)
Is "first" really the right color for this bikeshed? Maybe it's OK,
but speaking precisely you can't ask for "first" of a set. The
ques
>
> So while 1-arg next() and the try/except StopIteration pattern are
> essential and well-known, 2-arg next() is relatively esoteric and
> consequently (I think) not nearly as well-known.
>
And knowing that you must use *iter()* for 2-arg *next()* to (maybe) work
right is idiosyncratic.
It take
On Tue, 10 Dec 2019 at 00:26, Steven D'Aprano wrote:
>
> On Tue, Dec 10, 2019 at 10:54:10AM +1300, Greg Ewing wrote:
>
> > Can you provide any insight into why you think it's better for
> > it never to raise an exception, as opposed to raising something
> > other than StopIteration when the iterat
On Dec 9, 2019, at 17:16, Tim Peters wrote:
>
> [Steven D'Aprano ] wrote:
values = take(count, items, default=None)
>
> [MRAB]
>>> Why is the count first? Why not have the (definitely required) items
>>> first and let the count have a default of 1?
>
> [Steven]
>> I lifted the bulk of
[Steven D'Aprano ] wrote:
>>> values = take(count, items, default=None)
[MRAB]
>> Why is the count first? Why not have the (definitely required) items
>> first and let the count have a default of 1?
[Steven]
> I lifted the bulk of the function, including the signature, from the
> recipe in th
On Mon, Dec 09, 2019 at 12:35:28PM -0600, Tim Peters wrote:
> I would _much_ rather write - and read:
>
> a = first(iterable, default)
>
> than
>
> a = take(1, iterable, default)[0]
>
> for much the same reasons I'd much rather write and read "2" than
> "int(10 / 5)" ;-)
Fair enough.
On Tue, Dec 10, 2019 at 10:54:10AM +1300, Greg Ewing wrote:
> Can you provide any insight into why you think it's better for
> it never to raise an exception, as opposed to raising something
> other than StopIteration when the iterator is empty and no
> default is specified?
Speaking for myself,
One more and then I'll let this go.
On Mon, Dec 9, 2019 at 10:49 AM Andrew Barnert wrote:
> On Dec 8, 2019, at 21:41, Guido van Rossum wrote:
>
> I do have to admit that I'm probably biased because I didn't recall 2-arg
> next() myself until it was mentioned in this thread.
>
> That’s because y
On Mon, Dec 09, 2019 at 01:44:15AM +, MRAB wrote:
> > values = take(count, items, default=None)
[...]
> Why is the count first? Why not have the (definitely required) items
> first and let the count have a default of 1?
I lifted the bulk of the function, including the signature, from th
On Dec 9, 2019, at 12:08, Wes Turner wrote:
>
>
>> On Sat, Dec 7, 2019, 11:30 PM Andrew Barnert wrote:
>>> On Dec 7, 2019, at 18:09, Wes Turner wrote:
>>>
On Sat, Dec 7, 2019, 8:20 PM Andrew Barnert wrote:
>
> I would argue that there could be subclasses of ValueError for .one() that
On 12/9/2019 4:54 PM, Greg Ewing wrote:
On 9/12/19 7:37 am, Guido van Rossum wrote:
def first(it, /, default=None):
it = iter(it)
try:
return next(it)
except StopIteration:
return default
Can you provide any insight into why you think it's better for
it never
> On 9 Dec 2019, at 20:07, Wes Turner wrote:
>
> class TooShortValueError(ValueError):
> class TooLongValueError(ValueError):
>
I had to think about the short and long for a moment.
I'd suggest:
class TooManyItems(ValueError):
class TooFewItems(ValueError):
Barry
__
[Guido]
>> def first(it, /, default=None):
>> it = iter(it)
>> try:
>> return next(it)
>> except StopIteration:
>> return default
[Greg Ewing ]
> Can you provide any insight into why you think it's better for
> it never to raise an exception, as opposed to raising
On Mon, Dec 9, 2019 at 10:39 AM Tim Peters wrote:
> [Steven D'Aprano ]
> > What do you think of my suggestion that we promote the itertools recipe
> > "take" into a function?
> >
> >
> https://mail.python.org/archives/list/python-ideas@python.org/message/O5RYM6ZDXEB3OAQT75IADT4YLXE25HTT/
>
> That
On Mon, Dec 9, 2019 at 10:03 AM Tim Peters wrote:
> [Andrew Barnert ]
> > Didn’t PyPy already make the fix years ago of rewriting all of itertools
> > (for both 2.7 and 3.3 or whenever) as “Python builtins” in the underlying
> > namespace?
>
> I don't know.
>
> > Also, even if I’m remembering wro
On 9/12/19 7:37 am, Guido van Rossum wrote:
def first(it, /, default=None):
it = iter(it)
try:
return next(it)
except StopIteration:
return default
Can you provide any insight into why you think it's better for
it never to raise an exception, as opposed to rais
On Sat, Dec 7, 2019, 11:30 PM Andrew Barnert wrote:
> On Dec 7, 2019, at 18:09, Wes Turner wrote:
>
>
> On Sat, Dec 7, 2019, 8:20 PM Andrew Barnert wrote:
>
>> On Dec 7, 2019, at 07:33, Wes Turner wrote:
>> >
>> >
>> > +1 for itertools.first(seq, default=Exception) *and* itertools.one(seq,
>
On Dec 8, 2019, at 21:41, Guido van Rossum wrote:
>
>> On Sun, Dec 8, 2019 at 9:27 PM Andrew Barnert wrote:
>> On Dec 8, 2019, at 20:59, Guido van Rossum wrote:
>> >
>> > But even if you know about 2-arg next(), the next(iter(it), default)
>> > version is not quite trivial to come up with --
[Steven D'Aprano ]
> What do you think of my suggestion that we promote the itertools recipe
> "take" into a function?
>
> https://mail.python.org/archives/list/python-ideas@python.org/message/O5RYM6ZDXEB3OAQT75IADT4YLXE25HTT/
That it's independent of whether `first()` should be added.
I would _m
> On 9 Dec 2019, at 18:31, Andrew Barnert via Python-ideas
> wrote:
>
> On Dec 8, 2019, at 22:01, Tim Peters wrote:
>>
>> BTW, another change I'd make is to break the tradition of coding every
>> itertools function in C. That makes the implementation bar much
>> higher, and the other simil
[Andrew Barnert ]
> Didn’t PyPy already make the fix years ago of rewriting all of itertools
> (for both 2.7 and 3.3 or whenever) as “Python builtins” in the underlying
> namespace?
I don't know.
> Also, even if I’m remembering wrong, just writing a Python module in front
> of the C module, with
PyPy apart, we wouldn’t have to rewrite everything. It would just be
simpler to add new functions written in Python.
On Mon, Dec 9, 2019 at 09:29 Andrew Barnert wrote:
> On Dec 8, 2019, at 22:01, Tim Peters wrote:
> >
> > BTW, another change I'd make is to break the tradition of coding every
>
On Dec 8, 2019, at 22:01, Tim Peters wrote:
>
> BTW, another change I'd make is to break the tradition of coding every
> itertools function in C. That makes the implementation bar much
> higher, and the other similar packages (more_itertools,
> toolz.itertools) don't bother. There's also that p
On Sun, Dec 8, 2019 at 10:02 PM Tim Peters wrote:
> BTW, another change I'd make is to break the tradition of coding every
> itertools function in C. That makes the implementation bar much
> higher, and the other similar packages (more_itertools,
> toolz.itertools) don't bother. There's also th
On Mon, Dec 9, 2019 at 3:29 AM Serhiy Storchaka wrote:
> 09.12.19 07:41, Guido van Rossum пише:
> > Nobody is going to write a blog post about 2-arg next() (there just
> > isn't enough for more than a sentence or two) but people write tutorials
> > about itertools all the time, since it's such a
09.12.19 07:41, Guido van Rossum пише:
Nobody is going to write a blog post about 2-arg next() (there just
isn't enough for more than a sentence or two) but people write tutorials
about itertools all the time, since it's such a rich module. So I think
it's likely that first() will get some expo
35 matches
Mail list logo
