Depends on what d is.
type({})
So the result is {(1, 2): None}, but the ambiguity comes from the
definition of {}, not from my proposal.
Am 05.02.2020 18:19 schrieb Serhiy Storchaka:
05.02.20 14:27, Musbur пише:
I have one suggestion: Wouldn't it be useful for these operators to
also a
On Thu, Feb 6, 2020 at 7:42 PM Musbur wrote:
>
> Depends on what d is.
>
> >>> type({})
>
>
> So the result is {(1, 2): None}, but the ambiguity comes from the
> definition of {}, not from my proposal.
>
Actually, what Serhiy hinted at was a consequence (and, I would say, a
rather weird corner
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, *b
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 ar
One issue that's come up during PR review with Guido and Serhiy is, when
evaluating `a | b`, whether or not the default implementation should call an
overridden `copy()` method on `a` in order to create an instance of the correct
subclass (rather than a plain-ol' `dict`). For example, `defaultdi
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
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 left
Hi Brandt, very nice PEP. I have two questions here.
First:
> - The proposal in its current form is very easy to wrap your head around: "|"
> takes dicts, "|=" takes anything dict.update does.
I see this asymmetry between the | and |= mentioned a few times in the
PEP, but I don't see any ration
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 genera
> 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 ma
> I see this asymmetry between the | and |= mentioned a few times in the PEP,
> but I don't see any rationale other than "the authors have decided".
I agree that this probably deserves to be addressed. I can't speak for Steven,
but I know that my motivation here is to restrict `|` in order to av
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, print
06.02.20 21:38, Brandt Bucher пише:
One issue that's come up during PR review with Guido and Serhiy is, when
evaluating `a | b`, whether or not the default implementation should call an
overridden `copy()` method on `a` in order to create an instance of the correct
subclass (rather than a plai
> It would create an exception of two rules:
I don't think these are "rules", I think they're just "the way things are".
If I'm subclassing `dict`, and I see in the docs something to the effect of:
> By default, `dict` subclasses will return `dict` objects for `|` operations.
> To force the cre
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]` use
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 t
On 2/6/20 4:23 PM, Serhiy Storchaka wrote:
> It would create an exception of two rules:
>
> 1. Operators on subclasses of builtin classes do not depend on
> overridden methods of arguments (except the corresponding dunder
> method). `list.__add__` and `set.__or__` do not call copy() and
> extend()/
> but I think the desired semantics can all be achieved using only magic
> methods on the objects themselves
Hm. So, just to clarify, you're suggesting we use `__copy__`, if it exists?
Interesting...
___
Python-Dev mailing list -- python-dev@python.org
Sorry Paul, I sent my reply too soon.
I see what you're saying, and I'm pretty firmly -1 on reinventing (or
importing) copy.copy. We already have an API for copying a dict (dict.copy).
I still fail to see problem with using a method that doesn't start and end with
underscores, other than that
On Fri, Feb 7, 2020 at 9:30 AM Brandt Bucher wrote:
>
> Sorry Paul, I sent my reply too soon.
>
> I see what you're saying, and I'm pretty firmly -1 on reinventing (or
> importing) copy.copy. We already have an API for copying a dict (dict.copy).
>
> I still fail to see problem with using a metho
I don't have a terribly strong opinion about whether or not it is acceptable to
use dict.copy, my point was that the desired semantics can be achieved using
only dunder methods if desired, and I think at this point getting the semantics
right probably matters more than the implementation details
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 elemen
> > We already have an API for copying a dict (dict.copy). I still fail to see
> > problem with using a method that doesn't start and end with underscores,
> > other than that we "haven't done it".
>
> Before Python 3.0, iterators had a next() method, and that was explicitly and
> consciously ch
23 matches
Mail list logo
