On Sat, 7 Dec 2019 at 00:43, Steven D'Aprano wrote:
>
> On Fri, Dec 06, 2019 at 09:11:44AM -0400, Juancarlo Añez wrote:
>
> [...]
> > > Sure, but in this case, it isn't a fragment of a larger function, and
> > > that's not what it looks like. If it looked like what you wrote, I would
> > > underst
On Mon, Dec 9, 2019 at 12:48 AM Oscar Benjamin
wrote:
>
> On Sat, 7 Dec 2019 at 00:43, Steven D'Aprano wrote:
> >
> > On Fri, Dec 06, 2019 at 09:11:44AM -0400, Juancarlo Añez wrote:
> >
> > [...]
> > > > Sure, but in this case, it isn't a fragment of a larger function, and
> > > > that's not what
PEP 479 (https://www.python.org/dev/peps/pep-0479/) changed the rules
around generators: if it would have leaked StopIteration, it instead
raises RuntimeError. This converts hard-to-debug premature termination
into easily-spotted exceptions, but it applies only to actual
generator functions.
Imple
On Sun, 8 Dec 2019 at 14:37, Chris Angelico wrote:
>
> PEP 479 (https://www.python.org/dev/peps/pep-0479/) changed the rules
> around generators: if it would have leaked StopIteration, it instead
> raises RuntimeError. This converts hard-to-debug premature termination
> into easily-spotted excepti
On Mon, Dec 9, 2019 at 1:57 AM Oscar Benjamin
wrote:
>
> On Sun, 8 Dec 2019 at 14:37, Chris Angelico wrote:
> >
> > PEP 479 (https://www.python.org/dev/peps/pep-0479/) changed the rules
> > around generators: if it would have leaked StopIteration, it instead
> > raises RuntimeError. This converts
On 2019-12-08 12:38 p.m., Chris Angelico wrote:
On Mon, Dec 9, 2019 at 1:57 AM Oscar Benjamin
wrote:
>
> On Sun, 8 Dec 2019 at 14:37, Chris Angelico wrote:
> >
> > PEP 479 (https://www.python.org/dev/peps/pep-0479/) changed the rules
> > around generators: if it would have leaked StopIterati
We're not changing next(). It's too fundamental to change even subtly.
We might add itertools.first(), but not builtins.first(). This kind of
functionality is not fundamental but it's easy to get slightly wrong
(witness many hasty attempts in these threads).
itertools.first() should be implemente
> On 8 Dec 2019, at 19:40, Guido van Rossum wrote:
>
>
> We're not changing next(). It's too fundamental to change even subtly.
>
> We might add itertools.first(), but not builtins.first(). This kind of
> functionality is not fundamental but it's easy to get slightly wrong (witness
> many
On Sun, Dec 8, 2019 at 11:03 AM Anders Hovmöller
wrote:
>
>
> > On 8 Dec 2019, at 19:40, Guido van Rossum wrote:
> >
> > def first(it, /, default=None):
> > it = iter(it)
> > try:
> > return next(it)
> > except StopIteration:
> > return default
>
> Why ban the use of
> On 8 Dec 2019, at 20:11, Guido van Rossum wrote:
>
>
>> On Sun, Dec 8, 2019 at 11:03 AM Anders Hovmöller wrote:
>>
>>
>> > On 8 Dec 2019, at 19:40, Guido van Rossum wrote:
>> >
>> > def first(it, /, default=None):
>> > it = iter(it)
>> > try:
>> > return next(it)
>> >
[Guido]
> We're not changing next(). It's too fundamental to change even subtly.
Note that `next()` already accepts two arguments (the second is an
optional default in case its iterable argument is exhausted). Like:
>>> next(iter([]), 42)
42
> We might add itertools.first(), but not builtins.fi
On Sun, 8 Dec 2019 at 18:42, Guido van Rossum wrote:
>
> We're not changing next(). It's too fundamental to change even subtly.
I don't think that anyone has proposed to change the behaviour of
next. I have suggested that if there is to be a new function very
similar to next then it can also solv
On Sun, Dec 08, 2019 at 01:45:08PM +, Oscar Benjamin wrote:
> On Sat, 7 Dec 2019 at 00:43, Steven D'Aprano wrote:
[...]
> > But there's a major difference in behaviour depending on your input, and
> > one which is surely going to lead to bugs from people who didn't realise
> > that iterator a
On Sun, Dec 08, 2019 at 10:37:51AM -0800, Guido van Rossum wrote:
> We're not changing next(). It's too fundamental to change even subtly.
>
> We might add itertools.first(), but not builtins.first(). This kind of
> functionality is not fundamental but it's easy to get slightly wrong
> (witness ma
On 2019-12-09 01:04, Steven D'Aprano wrote:
On Sun, Dec 08, 2019 at 10:37:51AM -0800, Guido van Rossum wrote:
We're not changing next(). It's too fundamental to change even subtly.
We might add itertools.first(), but not builtins.first(). This kind of
functionality is not fundamental but it's e
On Sun, Dec 8, 2019 at 2:23 PM Oscar Benjamin
wrote:
> On Sun, 8 Dec 2019 at 18:42, Guido van Rossum wrote:
> >
> > We're not changing next(). It's too fundamental to change even subtly.
>
> I don't think that anyone has proposed to change the behaviour of
> next. I have suggested that if there
On Sun, Dec 8, 2019 at 5:20 PM Steven D'Aprano wrote:
> What do you think of my suggestion that we promote the itertools recipe
> "take" into a function?
>
>
> https://mail.python.org/archives/list/[email protected]/message/O5RYM6ZDXEB3OAQT75IADT4YLXE25HTT/
I'll leave it to others to weig
On Sun, Dec 8, 2019 at 2:09 PM Tim Peters wrote:
> [Guido]
> > We're not changing next(). It's too fundamental to change even subtly.
>
> Note that `next()` already accepts two arguments (the second is an
> optional default in case its iterable argument is exhausted). Like:
>
> >>> next(iter([])
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 -- you have to remember to put the
> iter() call in -- but IMO the main problem is that not enough people know
> about 2-arg
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 -- you have to remember to put
> the iter() call in -- but IMO the
[Guido]
> ...
> 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.
I knew about it once, but had forgotten all about it too until this
thread :-) Which does indeed make the case stronger for adding
itertools.first, e
21 matches
Mail list logo
