18.06.21 00:22, Ben Rudiak-Gould пише:
> Okay, slightly off-topic, but can we *please* allow
>
> [*chunk for chunk in list_of_lists]
>
> some day. I think it was left out because some discussion concluded it
> would be too confusing, which is ridiculous. I assumed it would work and
> was conf
David Mertz writes:
> On Thu, Jun 17, 2021, 5:24 PM Ben Rudiak-Gould
>
> > Okay, slightly off-topic, but can we *please* allow
> >
> > [*chunk for chunk in list_of_lists]
> >
>
> It is completely non-obvious to me what that would even MEAN. I cannot
> derive anything obvious from oth
On Fri, Jun 18, 2021 at 11:13 PM Stephen J. Turnbull
wrote:
> Serhiy writes that a reason for not allowing this is that you'd want
> to allow [x, y for x in l], splicing the x, y values into the result
> list. That doesn't make sense to me, for two reasons. x, y already
> has a meaning in that c
On Fri, Jun 18, 2021 at 00:43 Serhiy Storchaka wrote:
> 18.06.21 00:22, Ben Rudiak-Gould пише:
> > Okay, slightly off-topic, but can we *please* allow
> >
> > [*chunk for chunk in list_of_lists]
> >
> > some day. I think it was left out because some discussion concluded it
> > would be too co
I don't see how allowing
[x, y for x in a]
follows from allowing
[*chunk for chunk in list_of_lists].
___
Python-ideas mailing list -- [email protected]
To unsubscribe send an email to [email protected]
https://mail.python.org/mail
Is there somewhere where you can use "*ab" but not "a ,b" currently in
Python?
On Fri, Jun 18, 2021 at 11:43 AM Mathew Elman
wrote:
> I don't see how allowing
>
> [x, y for x in a]
>
> follows from allowing
>
> [*chunk for chunk in list_of_lists].
> _
On 18/06/2021 16:42, Mathew Elman wrote:
I don't see how allowing
[x, y for x in a]
follows from allowing
[*chunk for chunk in list_of_lists].
Nor do I.
Rob Cliffe
___
Python-ideas mailing list -- [email protected]
To unsubscribe send an e
On Fri, 18 Jun 2021, Serhiy Storchaka wrote:
18.06.21 00:22, Ben Rudiak-Gould пише:
Okay, slightly off-topic, but can we *please* allow
[*chunk for chunk in list_of_lists]
some day. I think it was left out because some discussion concluded it
would be too confusing, which is ridiculous. I
On Fri, Jun 18, 2021 at 10:10:33PM +0900, Stephen J. Turnbull wrote:
> Pretty clearly the * means ...
>
> It did take me a bit of thought to come to Ben's intended
> interpretation ...
So perhaps not actually that clear then? *wink*
In hindsight, after realising what Ben's intention was (at lea
Python raises TypeError when NotImplemented is returned from __add__,
__invert__ etc. and __radd__ etc. aren't available.
However, this disallows the customization of error messages. For example, in
Python 3.8, __float__ etc. were removed from complex to allow methods like
__rfloat__. But this m
On Fri, Jun 18, 2021 at 07:38:49AM -0700, Guido van Rossum wrote:
> Note the ambiguity around whether the user might have meant
>
> [x,(y for y in a)]
>
> or
>
> [(x, y) for y in a]
We already have a rule to disambiguate generator comprehensions: they
must always be parenthesized unle
On Fri, Jun 18, 2021 at 8:40 PM Steven D'Aprano wrote:
> On Fri, Jun 18, 2021 at 07:38:49AM -0700, Guido van Rossum wrote:
>
> > Note the ambiguity around whether the user might have meant
> >
> > [x,(y for y in a)]
> >
> > or
> >
> > [(x, y) for y in a]
>
> We already have a rule to disa
On Sat, Jun 19, 2021 at 03:30:05AM -, [email protected] wrote:
> Python raises TypeError when NotImplemented is returned from __add__,
> __invert__ etc. and __radd__ etc. aren't available.
Roughly correct. It's more complex than that.
> However, this disallows the customization of error mess
On Fri, Jun 18, 2021 at 09:33:49PM -0700, Guido van Rossum wrote:
> Now, this shouldn't be considered an airtight argument against [*chunk for
> ...], but it does show that there's no straightforward explanation of its
> meaning through equivalence (like the OP seemed to think), and I think this
>
14 matches
Mail list logo
