> > 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
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
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
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
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
> 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 --
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
>
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]`
> 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
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
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,
> 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
> 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 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
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
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,
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,
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
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
23 matches
Mail list logo
