This is my first post to this list, apologies in advance if this is the wrong
place or it's a known topic that my search failed to find.
As a Python user since 2.6, I make stupid mistakes with exhausted generators
more often than I'd like to admit:
numbers = (i for i in range(5))
assert 5 not i
> On 12 Jun 2023, at 16:55, BoppreH via Python-ideas
> wrote:
>
> Then the empty list creates hard-to-track bugs. I'm familiar with the
> iterator protocol and why the behavior above happens, but couldn't it be
> prevented?
I don’t think so. It is not always a bug that an iterator is empty.
I was wandering if there are any issues in making `yield` usage to be the same
as that of `await`
Most importantly:
l.append(yield Object())
Nice to have:
yield with Object():
yield for i in Object():
Also, could anyone point me in the direction, where it is explained why new
await/async synta
On Tue, 13 Jun 2023 at 07:33, Dom Grigonis wrote:
>
> I was wandering if there are any issues in making `yield` usage to be the
> same as that of `await`
>
> Most importantly:
> l.append(yield Object())
You should be able to use that, since yield *is* an expression. The
only oddity is, you have
That's a good scenario, but it doesn't traceback with the SafeGenerator
implementation above.
args = SafeGenerator(iter(['mkdir.py', 'dir']))
progname = next(args)
mandatory_arg = next(args)
# Generator is empty, but "we don't know it yet" (no StopIteration), so
is_exhausted == False
for arg in
On 12/06/2023 21:11, Barry wrote:
On 12 Jun 2023, at 16:55, BoppreH via Python-ideas
wrote:
Then the empty list creates hard-to-track bugs. I'm familiar with the iterator
protocol and why the behavior above happens, but couldn't it be prevented?
I don’t think so. It is not always a bug tha
On 13/06/23 9:59 am, Rob Cliffe via Python-ideas wrote:
Also the OP's request was for generators, not for any iterator.
IMO it would be a bad idea to make generators behave differently
from other iterators in this regard. And it's far too late to
redefine the iterator protocol in general, becau
On 13/06/23 9:29 am, Dom Grigonis wrote:
Also, could anyone point me in the direction, where it is explained why new
await/async syntax was introduced instead of making use of already existing
yield coroutine functionality?
To my mind, the fact that coroutines use the same underlying
mechanis
On Tue, 13 Jun 2023 at 09:33, Greg Ewing wrote:
>
> On 13/06/23 9:29 am, Dom Grigonis wrote:
> > Also, could anyone point me in the direction, where it is explained why new
> > await/async syntax was introduced instead of making use of already existing
> > yield coroutine functionality?
>
> To m
The problem with adding a second None-like type is that gradually it
will acquire meaning as a possible value in some contexts. Maybe not in
your code, but in other people's. Then will there be a request for a
3rd such object? (4th, 5th ...?).
Defining your own sentinel object, as you do, see
On 13/06/23 11:38 am, Chris Angelico wrote:
I think they currently use what's basically a copy of the generator
implementation. It makes sense to make resumable functions that way.
In many ways it does, although things get a bit messy
when it comes to async generators. If I were designing
somet
unittest.mock.sentinel did the trick for me. As long as there is something for
it in a standard library for it I think it’s covered. Everyone defining their
own classes or objects would be confusing.
> On 12 Jun 2023, at 14:27, Rob Cliffe via Python-ideas
> wrote:
>
> The problem with adding
On Tue, 13 Jun 2023 at 14:54, Greg Ewing wrote:
>
> On 13/06/23 11:38 am, Chris Angelico wrote:
> > (Fun fact: Pike looked at what Python was doing, and came up with a
> > concept of "continue functions"
>
> And I gather that the "async" and "await" keywords came
> from C#. Languages are always
13 matches
Mail list logo
