[Python-Dev] Re: Call for papers for PyCon 2020

[Claudio Jolowicz]

Dear Amna, thank you for your interest in my talk, and sorry for the late
reply. Unfortunately, I won't be able to make it this year. Please feel
free to reach out again in the future. Wishing you all the best, and thank
you for organizing this conference :) Claudio

On Thu, 6 Aug 2020 at 18:22, Amna Ahsan  wrote:

> Hi,
>
> I am writing to you on behalf of PyCon Estonia  to
> invite you to take part in the call for papers for our 2020 edition and
> join us as a speaker at PyCon: https://pyconestonia.typeform.com/to/e0jriV
>
>
> This is the third PyCon Estonia event after successful delivery in 2018
> and 2019. PyCon Estonia is organised by our NGO Python Estonia
>  which is dedicated to education and awareness
> about Python in the region.
>
> In previous years , keynote
> speakers at PyCon Estonia have included Travis Oliphant (Creator of
> NumPy) and Kristo Vaher (Govt. CTO of Estonia). We've had around 300
> participants join us for a live conference in Tallinn, Estonia with 7-9
> excellent speakers from all walks of life talking about Python. This year
> we already have Miguel Grinberg  as one
> of our speakers.
>
> Due to coronavirus, this PyCon will be an entirely virtual conference,
> possibly with a bigger and more international audience. The theme for
> PyCon Estonia 2020 is "The power of Python" and we want to talk about the
> real life applications of Python and how digital products built on Python
> are impacting the tech sector or the world in general.
>
> We would really like to have you offer a possible topic for a talk at
> PyCon. We intend to have a total of 8 talks of 30-minutes followed by a
> 10-minute Q If this would be something you are interested in, please
> submit a proposal here: https://pyconestonia.typeform.com/to/e0jriV
> before the *15th August, 2020*.
>
> I am happy to add that we are a diverse group organising PyCon Estonia
> 2020, and we are trying to make the conference as diverse as possible.
>
> If you have any questions, please don't hesitate to write to me.
>
> Best Regards,
>
> *Amna Ahsan*
> Chief Marketing Officer
>
> *Python Estonia*
> +372 5784 0436
> ___
> Python-Dev mailing list -- python-dev@python.org
> To unsubscribe send an email to python-dev-le...@python.org
> https://mail.python.org/mailman3/lists/python-dev.python.org/
> Message archived at
> https://mail.python.org/archives/list/python-dev@python.org/message/VR3Y7HSHVPL3T4NGN7YQ7HJ5SOBIO4XD/
> Code of Conduct: http://python.org/psf/codeofconduct/
>
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/XFQE7VRKMA3TLYBKKY3RD7HEBO263TYS/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Accepting PEP 584: Add Union Operators To dict

[Claudio Jolowicz]

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 C++ codebase where the `|=` operator was
sometimes
overloaded in such a way (since there is no `||=` operator in this
language).
Unfortunately, I have not found similar uses of `|=` elsewhere (e.g. in
Boost).

To illustrate this with a specific case nonetheless, that C++ codebase had a
generic data type modelled after Haskell's Maybe. In Haskell, `Maybe a` is a
type which can be empty (`Nothing`) or hold a value (`Just a`). In the C++
implementation, the operation `a |= b` would assign `just(b)` iff `a` was
not
empty.

About 1)

I still believe that there is an intuition that the right operand of `|` is
a
fallback value, and this intuition may lead people to wrong use of dict
unions.

To make this intuition more explicit: Consider other operations that behave
like
OR in a Boolean algebra, such as logical OR, and set union. Conceptually,
these
operations perform one or multiple checks on the left operand, and only
consider
the right operand if the check "failed".

- With logical OR, short-circuit semantics are widespread (cf. C, UNIX
shell, or
  Python itself). The right operand is only evaluated if the left operand
  evaluates to false in a Boolean context.

- With set union, implementations typically start by copying the left
operand,
  and add entries from the right operand if they are not already present in
the
  copy. This is also what CPython does in `set_union` (via `set_add_entry`).


As another case in point, overriding items from the right operand is already
provided by `dict.update`. A `|=` operator which provides for the
complementary
operation of filling in missing items would have made for a more orthogonal
set
of operations. When formulated in terms of `|`, the two operations only
differ
in the order of operands.

> Here's our current proposal for docs. Is there anything you'd like to add?
> https://github.com/python/cpython/pull/18659/files

I find this quite clear. It already points out the behaviour in question.


To conclude, different semantics for dict union would have been preferable
in my
view, but I guess that ship has sailed. Other than changing dict union
semantics
I don't think there is anything actionable left here. Maybe my input still
has
some value in clarifying expectations some users may have for this new
feature.

Thank you for your openness about this late input to the discussion.

On Thu, 27 Feb 2020 at 10:35, Kyle Stanley  wrote:

> > 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 "null" and "undefined" are considered falsey [1]. For
> example:
>
> > var value = null;
> > var other = 2;
> > value |= other;
> > console.log(value);
> 2
>
> So it effectively works like "value | other", but also sets "value" to
> "other" iff "value" is falsey. When the left-hand operand is truthy, it
> effectively does nothing.
>
> > var value = 3;
> > var other = 2;
> > value |= other;
> > console.log(value);
> 3
>
> Also worth noting, since "value |= other" translates to "value = value |
> other", it works as a bitwise OR operator; not as a catch-all for assigning
> a default value:
>
> > var value = null;
> > var other = "test";
> > value |= other;
> > console.log(value);
> 0
>
> Instead, you'd have to use the standard OR operator, like this "value =
> value || other" (since "||=" is invalid syntax):
>
> > var value = null;
> > var other = "test";
> > value = value || other;
> > console.log(value);
> test
>
> FWIW, I have very rarely seen "|=" used as an operator in JS, but I've
> seen "value = value || other" used a decent amount.
>
> ---
>
> [1] - https://developer.mozilla.org/en-US/docs/Glossary/Falsy
>
>
>
> On Wed, Feb 26, 2020 at 6:26 PM Nick Coghlan  wrote:
>
>>
>>
>> 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

[Python-Dev] Re: Accepting PEP 584: Add Union Operators To dict

[Claudio Jolowicz]

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 that this behavior has many use-cases

This is probably based on a thorough analysis of usage patterns, but the
result
still surprises me. I could not find the related discussion in the mail
archives. Could you elaborate, or point to more detailed information?

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
applied
element-wise. In other words, the resulting dict would have the union of
keys,
with values supplied from `other` only if keys are missing in `value`.

This would allow users to provide defaults in a dictionary of settings, like
this:

settings |= defaults

As this usage generalizes a (perceived) common idiom, I would expect people
to
get bitten by this.

Claudio

On Mon, 17 Feb 2020 at 22:05, Guido van Rossum  wrote:

> 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 just send my recommendation to accept the PEP to the
> Steering Council -- they will then let us know whether they agree, and once
> that's done we can update the PEP with the "Accepted" status and land the
> implementation (https://github.com/python/cpython/pull/12088). (Hm, the
> PEP should probably also link to that PR rather than to Brandt's private
> branch.)
>
> --
> --Guido van Rossum (python.org/~guido)
> *Pronouns: he/him **(why is my pronoun here?)*
> 
> ___
> Python-Dev mailing list -- python-dev@python.org
> To unsubscribe send an email to python-dev-le...@python.org
> https://mail.python.org/mailman3/lists/python-dev.python.org/
> Message archived at
> https://mail.python.org/archives/list/python-dev@python.org/message/6KT2KIOTYXMDCD2CCAOLOI7LUGTN6MBS/
> Code of Conduct: http://python.org/psf/codeofconduct/
>
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/VRR6XTPQXGGCDNMBUMR7RVRAOOOILJEW/
Code of Conduct: http://python.org/psf/codeofconduct/