Thanks for your response Serhiy.
> Yes, but this is a different thing. You must to implement new __or__ in a
> subclass to make the behavior of d1 | d2 be different from {**d1, **d2}.
Really? I'm sorry, but this doesn't feel like a real argument to me.
There was no clear compatible path
Let me split my case into two points:
1) The intuition that the right-hand side of `a | b` is a fallback value
2) The claim that `a |= b` is a common idiom to assign defaults
About 2)
It appears that the idiom in 2) is less common than I assumed. My
expectations
were shaped by working with a
On Thu, Feb 27, 2020 at 8:15 PM Serhiy Storchaka wrote:
>
> 27.02.20 10:46, Chris Angelico пише:
> > On Thu, Feb 27, 2020 at 7:41 PM Serhiy Storchaka
> > wrote:
> >> sympy/utilities/runtests.py
> >>
> >> Sorry, but the current code
> >>
> >> globs = globs.copy()
> >> if extraglobs is not None:
> So I've also never come across "|=" being used for this purpose.
IIRC, the JavaScript implementation of "|=" can potentially be used in the
way Claudio described it, instead it's based on the truthiness of the
left-hand operand rather than it being "unset". But it works in that
context because
27.02.20 10:46, Chris Angelico пише:
On Thu, Feb 27, 2020 at 7:41 PM Serhiy Storchaka wrote:
sympy/utilities/runtests.py
Sorry, but the current code
globs = globs.copy()
if extraglobs is not None:
globs.update(extraglobs)
looks much clearer to me than the proposed
globs = globs |
On Thu, Feb 27, 2020 at 7:41 PM Serhiy Storchaka wrote:
> sympy/utilities/runtests.py
>
> Sorry, but the current code
>
> globs = globs.copy()
> if extraglobs is not None:
> globs.update(extraglobs)
>
> looks much clearer to me than the proposed
>
> globs = globs | (extraglobs if extraglobs
18.02.20 19:35, Brandt Bucher пише:
...it was decided that `d1 | d2` also should ignore the types of the operands and always
return a dict. And it accepts only dicts, not general mappings, in difference to `{**d1,
**d2}`. So the only disadvantage of `{**d1, **d2}` is that it is not well known
Maybe it's more the `a ||= b` that acts like a `a = a or b` in Python?
But then I don't think there is a confusion on Python side because
languages with a || operator usually already has a simple | with a
different meaning.
Le jeu. 27 févr. 2020 à 00:28, Nick Coghlan a écrit :
>
>
>
> On Thu.,
On Thu., 27 Feb. 2020, 2:03 am Guido van Rossum, wrote:
> On Wed, Feb 26, 2020 at 7:43 AM Claudio Jolowicz
> wrote:
>
>> In my experience, the expression `value |= other` is a common idiom across
>> programming languages to provide a default for `value` if it is "unset".
>>
>
> Interesting. Can
Here's our current proposal for docs. Is there anything you'd like to add?
https://github.com/python/cpython/pull/18659/files
On Wed, Feb 26, 2020 at 8:12 AM David Mertz wrote:
> I think the "if unset" behavior is well handled by collections.ChainMap.
> But I do think that fact should be
I think the "if unset" behavior is well handled by collections.ChainMap.
But I do think that fact should be prominent in any documentation of the
new dict Union operator.
On Wed, Feb 26, 2020, 11:06 AM Guido van Rossum wrote:
> On Wed, Feb 26, 2020 at 7:43 AM Claudio Jolowicz
> wrote:
>
>> In
On Wed, Feb 26, 2020 at 7:43 AM Claudio Jolowicz
wrote:
> In my experience, the expression `value |= other` is a common idiom across
> programming languages to provide a default for `value` if it is "unset".
> For a
> container-type, I would expect this operation, informally spoken, to be
>
First off, apologies for entering the discussion after it has formally
ended.
I'm not sure this has any relevance now that the PEP is accepted and the
reference implementation merged. If not, sorry and feel free to ignore.
"Leftmost Value (First-Seen) Wins" was rejected because
> it is not clear
On Mon, 24 Feb 2020 at 12:10, Guido van Rossum wrote:
>
> On Sat, Feb 22, 2020 at 4:45 PM Brandt Bucher wrote:
>>
>> [quoting Nick]
>> > collections.Mapping and collections.MutableMapping could provide concrete
>> > method implementations that make subclasses behave in a way that's similar
>>
On Mon, Feb 24, 2020 at 10:42 AM Brandt Bucher
wrote:
> > Are these three cookie classes sufficiently popular that we need to
> support `|` on them?
>
> I don't have much experience with `http`, so I figured I'd open a BPO
> issue and let the relevant folks make the call. The main reason I'm
>
> Are these three cookie classes sufficiently popular that we need to support
> `|` on them?
I don't have much experience with `http`, so I figured I'd open a BPO issue and
let the relevant folks make the call. The main reason I'm considering these is
that `Morsel` was updated back in 3.5 with
On Sat, Feb 22, 2020 at 10:09 PM Steven D'Aprano
wrote:
> On Tue, Feb 18, 2020 at 05:35:38PM -, Brandt Bucher wrote:
> > > I am accepting this PEP. Congratulations Steven and Brandt!
> >
> > Thank you for your guidance, especially the suggestions late last
> > year. And thanks Steven for
On Sat, Feb 22, 2020 at 4:45 PM Brandt Bucher
wrote:
> [quoting Nick]
> > collections.Mapping and collections.MutableMapping could provide
> concrete method implementations that make subclasses behave in a way that's
> similar to built-in dicts
>
> Hm, haven't thought too much about this (I
On Sat, Feb 22, 2020 at 11:28 AM Brandt Bucher
wrote:
> Just to follow up on this, here are the subclasses I've found.
>
> Should be updated:
> - collections.OrderedDict
> - collections.defaultdict
>
SGTM.
- http.cookies.BaseCookie
> - http.cookies.Morsel
> - http.cookies.SimpleCookie
>
Are
On Tue, Feb 18, 2020 at 05:35:38PM -, Brandt Bucher wrote:
> > I am accepting this PEP. Congratulations Steven and Brandt!
>
> Thank you for your guidance, especially the suggestions late last
> year. And thanks Steven for taking me on as a co-author and shaping
> the bulk of the proposal.
> we'll also want to look at collections.UserDict, collections.ChainMap, and
> types.MappingProxyType.
UserDict has already been updated in the PR (it has tests that fail if it
doesn't have all of dict's methods). I'll look into the others... thanks for
reminding me!
> collections.Mapping and
On Sun., 23 Feb. 2020, 5:32 am Brandt Bucher,
wrote:
> Just to follow up on this, here are the subclasses I've found.
>
> Should be updated:
> - collections.OrderedDict
> - collections.defaultdict
> - http.cookies.BaseCookie
> - http.cookies.Morsel
> - http.cookies.SimpleCookie
>
They're not
Just to follow up on this, here are the subclasses I've found.
Should be updated:
- collections.OrderedDict
- collections.defaultdict
- http.cookies.BaseCookie
- http.cookies.Morsel
- http.cookies.SimpleCookie
Don’t think so:
- typing.TypedDict
Already defines the operator:
-
> In particular, you may want to update the implementations of defaultdict and
> ordereddict. (are there others?)
I have a checklist for PEP 584 follow-up PRs I'm planning to make after (and
if) it is accepted. typeshed stubs, docs, and `defaultdict` were on it. I'll
add `OrderedDict` as well
On Tue, Feb 18, 2020 at 9:40 AM Brandt Bucher
wrote:
>
> Now, addressing Serhiy's points :)...
>
> > ...it was decided that `d1 | d2` also should ignore the types of the
> operands and always return a dict. And it accepts only dicts, not general
> mappings, in difference to `{**d1, **d2}`. So
> I am accepting this PEP. Congratulations Steven and Brandt!
Thank you for your guidance, especially the suggestions late last year. And
thanks Steven for taking me on as a co-author and shaping the bulk of the
proposal.
> Hm, the PEP should probably also link to that PR rather than to
17.02.20 23:02, Guido van Rossum пише:
Now that the last bits of discussion about PEP 584 have been settled (we
will *not* be calling the `copy` or `update` methods) I am accepting
this PEP. Congratulations Steven and Brandt!
Thanks to everyone else who gave their opinion.
Formally, I will
27 matches
Mail list logo
