I am trying to release comfortable dataclass unpacking using `**` operator. Now
I have 5 different ways to do it.
But not a single good one. Confused by the implementation of the unpacking
operator.
So when I try to unpack any custom class, I get the error:
`type object argument after ** must b
> On 24 Dec 2020, at 17:15, Michael A. Smith wrote:
>
> With all the buffering that modern disks and filesystems do, a
> specific question has come up a few times with respect to whether or
> not data was actually written after flush. I think it would be pretty
> useful for the standard librar
Currently, asynchronous generators don't allow a non-empty `return` statement:
```python
import asyncio
async def async_generator():
x = yield 1
await asyncio.sleep(1)
if x:
...
return "result A" # SyntaxError
else:
...
return "result B"
```
unlik
I guess this can be extended to "allow `yield from` with asynchronous
generators", maybe something like `async yield from`.
___
Python-ideas mailing list -- [email protected]
To unsubscribe send an email to [email protected]
https://mai
My first thought is that for dataclasses, you can use the asdict() method,
and you're done.
But sure -- why not make it more generic.
It does seem like ** could be usable with any iterable that returns pairs
of objects. However the trick is that when you iterate a dict, you get the
keys, not the
On 2020-12-22 14:01, Steven D'Aprano wrote:
It seems to me that the primary use for this will be in the interactive
interpreter. People are used to something like "cls" or "clear" from
various shells. Using it in scripting is, I think, a secondary use-case.
Given that, I think that like othe
Sorry for the duplicate, Barry. I got bit by the "I don't reply-all by
default" spider.
On Sat, Dec 26, 2020 at 12:30 PM Barry Scott wrote:
>
>
> > On 24 Dec 2020, at 17:15, Michael A. Smith wrote:
> >
> > With all the buffering that modern disks and filesystems do, a
> > specific question has
Also sorry for the duplicate, Steven.
On Thu, Dec 24, 2020 at 5:31 PM Steven D'Aprano wrote:
> On Thu, Dec 24, 2020 at 12:15:08PM -0500, Michael A. Smith wrote:
>
> > With all the buffering that modern disks and filesystems do, a
> > specific question has come up a few times with respect to whet
On 27/12/20 10:15 am, Christopher Barker wrote:
It does seem like ** could be usable with any iterable that returns
pairs of objects. However the trick is that when you iterate a dict, you
get the keys, not the items, which makes me think that the only thing
you should *need* is an items() meth
On Thu, Dec 24, 2020 at 6:18 PM Cameron Simpson wrote:
>
> On 25Dec2020 09:29, Steven D'Aprano wrote:
> >On Thu, Dec 24, 2020 at 12:15:08PM -0500, Michael A. Smith wrote:
> >
> >> With all the buffering that modern disks and filesystems do, a
> >> specific question has come up a few times with re
On Thu, Dec 24, 2020 at 06:06:32PM -0600, re:fi.64 wrote:
> At least on Linux, this wouldn't be that ideal. These LWN articles go over
> the general fsync mess and the lack of viable alternatives:
>
> https://lwn.net/Articles/351422/
But isn't that a trade-off application developers can make for
On Sat, Dec 26, 2020 at 07:39:42PM -0500, Michael Smith wrote:
> I love context managers when they're alone, but I dislike stacking
> them. It is less clear how we can ensure the fsync happens exactly
> between flush and close with a context manager than a keyword argument
> to open. That is, if o
On Sat, Dec 26, 2020 at 4:35 PM Greg Ewing
wrote:
> On 27/12/20 10:15 am, Christopher Barker wrote:
> > ... the only thing
> > you should *need* is an items() method that returns an iterable (pf
> > pairs of objects).
>
> It seems to me it would be more fundamental to use iteration to get
> the k
>
> On 2020-12-22 14:01, Steven D'Aprano wrote:
> > It seems to me that the primary use for this will be in the interactive
> > interpreter. People are used to something like "cls" or "clear" from
> > various shells. Using it in scripting is, I think, a secondary use-case.
>
'
I disagree. yes, I wa
On Sun, Dec 27, 2020 at 01:34:02PM +1300, Greg Ewing wrote:
> On 27/12/20 10:15 am, Christopher Barker wrote:
> >It does seem like ** could be usable with any iterable that returns
> >pairs of objects. However the trick is that when you iterate a dict, you
> >get the keys, not the items, which ma
On Sun, Dec 27, 2020 at 11:36 AM Greg Ewing wrote:
>
> On 27/12/20 10:15 am, Christopher Barker wrote:
> > It does seem like ** could be usable with any iterable that returns
> > pairs of objects. However the trick is that when you iterate a dict, you
> > get the keys, not the items, which makes m
On 2020-12-26 18:00, Steven D'Aprano wrote:
On Sun, Dec 27, 2020 at 01:34:02PM +1300, Greg Ewing wrote:
On 27/12/20 10:15 am, Christopher Barker wrote:
>It does seem like ** could be usable with any iterable that returns
>pairs of objects. However the trick is that when you iterate a dict, you
>
On 2020-12-26 18:03, Chris Angelico wrote:
On Sun, Dec 27, 2020 at 11:36 AM Greg Ewing wrote:
On 27/12/20 10:15 am, Christopher Barker wrote:
> It does seem like ** could be usable with any iterable that returns
> pairs of objects. However the trick is that when you iterate a dict, you
> get t
On 2020-12-26 16:34, Greg Ewing wrote:
On 27/12/20 10:15 am, Christopher Barker wrote:
It does seem like ** could be usable with any iterable that returns
pairs of objects. However the trick is that when you iterate a dict, you
get the keys, not the items, which makes me think that the only thin
On Sat, Dec 26, 2020 at 05:58:16PM -0800, Christopher Barker wrote:
> >
> > On 2020-12-22 14:01, Steven D'Aprano wrote:
> > > It seems to me that the primary use for this will be in the interactive
> > > interpreter. People are used to something like "cls" or "clear" from
> > > various shells. Usin
On Sun, Dec 27, 2020 at 1:15 PM Brendan Barnwell wrote:
>
> On 2020-12-26 18:03, Chris Angelico wrote:
> > On Sun, Dec 27, 2020 at 11:36 AM Greg Ewing
> > wrote:
> >>
> >> On 27/12/20 10:15 am, Christopher Barker wrote:
> >> > It does seem like ** could be usable with any iterable that returns
>
On Sat, Dec 26, 2020 at 06:09:42PM -0800, Brendan Barnwell wrote:
> On 2020-12-26 18:00, Steven D'Aprano wrote:
> >I think if we were designing mapping protocols now, that would be an
> >excellent idea, but we aren't, we have decades of history from `dict`
> >behind us. And protocols from dict use
On 27/12/20 3:03 pm, Chris Angelico wrote:
But that would mean that a lot of iterables would look like mappings
when they're not.
In the context of ** you're expecting a mapping, not a sequence.
--
Greg
___
Python-ideas mailing list -- python-ideas@p
On 2020-12-26 18:44, Steven D'Aprano wrote:
> >I think if we were designing mapping protocols now, that would be an
> >excellent idea, but we aren't, we have decades of history from `dict`
> >behind us. And protocols from dict use `keys()` and getitem. E.g.
> >update.
>
>What do you mean by
On Sun, Dec 27, 2020 at 1:25 PM Steven D'Aprano wrote:
> But the ctrl-L trick has no discoverability. It took me close to twenty
> years of using Linux before I discovered it, and I still don't remember
> to use it when I need it.
>
> Beginners and casual users aren't going to know ctrl-L, or stum
On Sun, Dec 27, 2020 at 1:45 PM Greg Ewing wrote:
>
> On 27/12/20 3:03 pm, Chris Angelico wrote:
> > But that would mean that a lot of iterables would look like mappings
> > when they're not.
>
> In the context of ** you're expecting a mapping, not a sequence.
>
Exactly; and under the proposal I
On 2020-12-27 at 13:24:34 +1100,
Steven D'Aprano wrote:
> But the ctrl-L trick has no discoverability. It took me close to
> twenty years of using Linux before I discovered it, and I still don't
> remember to use it when I need it.
The first time a sysadmin added readline to one of our work comp
On Sat, Dec 26, 2020 at 06:52:46PM -0800, Brendan Barnwell wrote:
> On 2020-12-26 18:44, Steven D'Aprano wrote:
> >I think if we were designing mapping protocols now, that would be an
> >excellent idea, but we aren't, we have decades of history from `dict`
> >behind us. And protocols
On Sun, Dec 27, 2020 at 02:00:00PM +1100, Chris Angelico wrote:
> This is actually the exact part that I think should *not* happen, for
> several reasons:
>
> 1) Stuff that exists interactively and doesn't exist in a script is a
> barrier to that migration. I don't think this feature justifies th
On 2020-12-26 21:02, Steven D'Aprano wrote:
On Sat, Dec 26, 2020 at 06:52:46PM -0800, Brendan Barnwell wrote:
On 2020-12-26 18:44, Steven D'Aprano wrote:
>I think if we were designing mapping protocols now, that would be an
>excellent idea, but we aren't, we have decades of history fro
On Sun, Dec 27, 2020 at 4:30 PM Brendan Barnwell wrote:
> That said. . . I'm starting to wonder why not just create a new dunder
> called __items__ and have dict alias that to .items(). Then the
> **-unpacking protocol could use that and everything would be fine, right?
>
+0.95.
If we c
On Sun, Dec 27, 2020 at 4:26 PM Steven D'Aprano wrote:
>
> On Sun, Dec 27, 2020 at 02:00:00PM +1100, Chris Angelico wrote:
>
> > This is actually the exact part that I think should *not* happen, for
> > several reasons:
> >
> > 1) Stuff that exists interactively and doesn't exist in a script is a
26.12.20 13:23, Anton Abrosimov пише:
> I am trying to release comfortable dataclass unpacking using `**` operator.
> Now I have 5 different ways to do it.
> But not a single good one. Confused by the implementation of the unpacking
> operator.
>
> So when I try to unpack any custom class, I get
33 matches
Mail list logo
