I agree that if this is only in 3.9 then this is a cleanup of semantics that
were a bit off and should stay but get a mention in What's New.
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
On Fri, Feb 7, 2020 at 1:48 AM Mark Shannon wrote:
> Including the function name in the error message is misleading.
>
> "TypeError: print() argument after * must be an iterable, not int"
> implies that the error is related to `print`. It is not; the error is
> entirely on the caller's side. The
On 06/02/2020 9:56 pm, Serhiy Storchaka wrote:
06.02.20 08:28, Brandt Bucher пише:
Commits 13bc139 and 8a4cd70 introduced subtle changes in the
evaluation logic of unpacking operations. Previously, all elements
were evaluated prior to being collected in a container. Now, these
operations
07.02.20 01:00, Guido van Rossum пише:
How did we move from [*a,...] to print(*a,...)? They are quite different.
They are quite similar. The code for `(*a, *b, *c)` is:
1 0 LOAD_NAME0 (a)
2 LOAD_NAME1 (b)
4 LOAD_NAME
Sorry, ignore that - I see Serhiy used "print(*a)".
Paul
On Fri, 7 Feb 2020 at 08:10, Paul Moore wrote:
>
> On Thu, 6 Feb 2020 at 23:14, Guido van Rossum wrote:
> >
> > How did we move from [*a,...] to print(*a,...)? They are quite different.
>
> It was a good way to demonstrate evaluation
On Thu, 6 Feb 2020 at 23:14, Guido van Rossum wrote:
>
> How did we move from [*a,...] to print(*a,...)? They are quite different.
It was a good way to demonstrate evaluation order, as an expression
with a visible side effect. What the expression [print("a"), *None,
print("b")] prints before the
How did we move from [*a,...] to print(*a,...)? They are quite different.
On Thu, Feb 6, 2020 at 14:07 Serhiy Storchaka wrote:
> 06.02.20 08:28, Brandt Bucher пише:
> > Commits 13bc139 and 8a4cd70 introduced subtle changes in the evaluation
> logic of unpacking operations. Previously, all
Then there’s nothing to do here right? Or just add it to whatsnew?
On Thu, Feb 6, 2020 at 13:20 Brandt Bucher wrote:
> > We should fix that (by reverting to 3.8.1 behaviour) before 3.8.2 gets
> released.
>
> The commits which changed the behavior were bytecode/compiler changes that
> only went
06.02.20 08:28, Brandt Bucher пише:
Commits 13bc139 and 8a4cd70 introduced subtle changes in the evaluation logic of unpacking
operations. Previously, all elements were evaluated prior to being collected in a container. Now,
these operations are interleaved. For example, the code `[*a, *b]`
I like Mark’s new semantics better, but agree with the point about this
being a “feature”.
On Thu, Feb 6, 2020 at 13:06 Paul Moore wrote:
> On Thu, 6 Feb 2020 at 20:17, Mark Shannon wrote:
> >
> > I recently unintentionally changed the semantics of this expression
> > `[print("a"), *None,
> We should fix that (by reverting to 3.8.1 behaviour) before 3.8.2 gets
> released.
The commits which changed the behavior were bytecode/compiler changes that only
went to master. I don't think they are present on any other branches.
___
Python-Dev
On Thu, 6 Feb 2020 at 20:17, Mark Shannon wrote:
>
> I recently unintentionally changed the semantics of this expression
> `[print("a"), *None, print("b")]`.
> PEP 448 states that this should raise an exception, but does not specify
> evaluation order.
>
> My implementation was based on the
Hi everyone,
I recently unintentionally changed the semantics of this expression
`[print("a"), *None, print("b")]`.
PEP 448 states that this should raise an exception, but does not specify
evaluation order.
My implementation was based on the general principle that evaluation in
Python is
On 2/6/2020 2:26 PM, Mark Shannon wrote:
In the python grammar, an 'expression' is a 'starred_item' but a
'starred_item' need not be an expression.
starred_item ::= expression | "*" or_expr
expression ::= conditional_expression | lambda_expr
conditional_expression ::= or_test ["if" or_test
On 06/02/2020 6:30 pm, Terry Reedy wrote:
On 2/6/2020 1:28 AM, Brandt Bucher wrote:
Commits 13bc139 and 8a4cd70 introduced subtle changes in the
evaluation logic of unpacking operations. Previously, all elements
were evaluated prior to being collected in a container. Now, these
operations
On 2/6/2020 1:28 AM, Brandt Bucher wrote:
Commits 13bc139 and 8a4cd70 introduced subtle changes in the evaluation logic of unpacking
operations. Previously, all elements were evaluated prior to being collected in a container. Now,
these operations are interleaved. For example, the code `[*a,
16 matches
Mail list logo
