> So can we just finish PEP 584 without the .copy() call?
Sounds good. I’ll update the implementation and open a PR to the PEPs repo
later tonight. Thanks everybody!
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to py
On Sun, Feb 16, 2020 at 02:12:48PM -0800, Guido van Rossum wrote:
> So can we just finish PEP 584 without the .copy() call?
Fine by me.
Thanks to everyone!
--
Steven
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to
So can we just finish PEP 584 without the .copy() call? Surely the more
general solution will not be ready for Python 3.9, while PEP 584 is nearly
done. (I'm also skeptical about a general solution, but I'd rather stay out
of that discussion for a while longer, and maybe you all come up with
someth
Brandt Bucher wrote:
> This leads me to believe that we’re approaching the problem wrong. Rather
> than making a
> copy and working on it, I think the problem would be better served by a
> protocol that runs
> the default implementation, then calls some under hook on the subclass to
> build a
>
After a few days of thinking and experimenting, I’ve been convinced that `copy`
(and also `__copy__`) is not the right protocol for what we want to do here. I
believe that 584 can likely continue without subclass-preserving behavior, but
that better behavior could perhaps could be added to *all*
Thank you to everyone for your patience while I dragged my feet
responding to this. It's not because of a lack of interest, just a lack
of uninterrupted time to focus on this :-)
I believe that the final sticking points are the behaviour with
subclasses and whether or not the union operator oug
It looks to me like dict.__copy__ is not implemented, does anyone know why it's
not basically an alias for dict.copy?
If it's just random happenstance, presumably we could move dict.copy to
__copy__ and then have dict.copy as an alias or thin wrapper. It might be
desirable anyway for copy.copy
I agree that if we want to go down the road of creating a copy to allow for
subclasses then we should define a dunder method for such a use, even if it's
redundant in the face of dict.copy().
___
Python-Dev mailing list -- python-dev@python.org
To unsub
07.02.20 01:00, Paul G пише:
I will note that it doesn't seem to be true that operators never call
standard methods. Looks like date.__add__ calls date.toordinal and
date.fromordinal (at least in the pure Python implementation), and
datetime calls those plus tzinfo.utcoffset. Not sure if the ru
> > 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
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
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
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 -- python-dev@python.org
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()/
> 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 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
> 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
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
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 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 a
05.02.20 14:27, Musbur пише:
I have one suggestion: Wouldn't it be useful for these operators to also
accept sets (functionally acting like a dict with None for all values)?
This would make it very elegant to 'normalize' dicts by pruning (dict &
set) or padding (set | dict) dictionaries. I woul
On Thu, Feb 6, 2020 at 3:47 AM Brandt Bucher wrote:
>
> > I have one suggestion: Wouldn't it be useful for these operators to also
> > accept sets (functionally acting like a dict with None for all values)?
>
> > Why None? Why not 0, or False, or 42? This sort of thing belongs more in
> > a f
> I have one suggestion: Wouldn't it be useful for these operators to also
> accept sets (functionally acting like a dict with None for all values)?
> Why None? Why not 0, or False, or 42? This sort of thing belongs more in a
> function or method, IMHO.
Well, in their defense, None is the nu
On 05/02/2020 12:27, Musbur wrote:
I have one suggestion: Wouldn't it be useful for these operators to also
accept sets (functionally acting like a dict with None for all values)?
This would make it very elegant to 'normalize' dicts by pruning (dict &
set) or padding (set | dict) dictionaries.
This is a great PEP. Just recently I needed this and was surprised that
nothing of the sort had been implemented yet (I looked for quite some
time).
I have one suggestion: Wouldn't it be useful for these operators to also
accept sets (functionally acting like a dict with None for all values)?
It already has a PR open against master, with all tests passing:
https://github.com/python/cpython/pull/12088
Sorry about the messy history - this proposal has changed significantly several
times over the past year (at least as far as the implementation is concerned).
At one point, both operato
Thanks Brandt (and Steven of course)! If there are no objections by next
week I'll recommend this to the Steering Council for acceptance.
In the meantime, I am wondering about the reference implementation -- is it
suitable to submit as a PR? Or is it a toy written in pure Python? (I found
it a lit
29 matches
Mail list logo
