Mailing List Archive

Thanks -- this is the kind of work that helps a PEP get accepted. I am
personally in favor of accepting PEP 505, and I hope that your work and the
discussion that will undoubtedly follow here will help convince the
Steering Council to accept it.

--Guido

On Thu, Oct 14, 2021 at 10:38 AM Doug Swarin <dswarin@gmail.com> wrote:

> Hello,
>
> I've been following PEP 505 (https://www.python.org/dev/peps/pep-0505/)
> since it was first proposed for Python 3.8. It's been deferred for some
> time and I'm interested in seeing it in Python 3.11, but I know there were
> also a number of objections which resulted in it being deferred (including
> by one of the original authors, Mr. Dower). I did email both Mr. Dower and
> Mr. Haase and they graciously gave me their permission to bring it up on
> this list for discussion and hopefully final pronouncement one way or the
> other.
>
> I personally believe that the PEP will result in a significant reduction
> in boilerplate code, and it is substantially similar to the same operators
> now found in a number of other languages, especially C# and JavaScript (
> https://wikipedia.org/wiki/Null_coalescing_operator and
> https://wikipedia.org/wiki/Safe_navigation_operator).
>
> I believe strong and valid arguments can be made about the use of None
> being a fundamental flaw in some types of coding (and that adding
> additional support for it to the language will increase the use of None in
> this way), but I also believe there are many use cases in programming where
> it is by far the simplest way to express various semantics, and the fact
> exists that None is already used extensively in large quantities of code,
> and further that there is already a great deal of code written to
> constantly test against None and break out of a statement without throwing
> an error.
>
> I also understand the argument that especially the maybe-dot (?.) and
> maybe-subscript (?[) operators can decrease readability of code and also
> believe these are valid arguments against it. While I believe the existence
> and use of these operators in other languages definitely helps the case
> that these can be used and understood successfully, I think it is entirely
> valid to either consider other syntax (though I prefer the chosen syntax of
> PEP 505), or even to reduce PEP 505 to having only the coalesce operator
> (??) and the maybe-assign operator (??=).
>
> Separately, I have implemented a pure-Python solution for PEP505 (which is
> definitely rather beta) which might help test the waters for a final
> implementation in CPython (though the CPython implementation would of
> course be much more efficient). It can be found at
> https://pypi.org/project/pep505/
>
> Thanks,
> Doug
> _______________________________________________
> Python-Dev mailing list -- python-dev@python.org
> To unsubscribe send an email to python-dev-leave@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/XZZIV42XGG3EIHRBBCCTTCFPWWSOT7MX/
> Code of Conduct: http://python.org/psf/codeofconduct/
>


--
--Guido van Rossum (python.org/~guido)
*Pronouns: he/him **(why is my pronoun here?)*
<http://feministing.com/2015/02/03/how-using-they-as-a-singular-pronoun-can-change-the-world/>

I tried to implement this in CPython by modifying a downloaded source code, but I can't seem to fix the problem of the "maybe" operators segfaulting when being used with literal immutables. The maybe-assign/coalesce operators were implemented successfully though.
_______________________________________________
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-leave@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/2TGUBJFMNKTCG4IIOE444CYIUT4GZBDI/
Code of Conduct: http://python.org/psf/codeofconduct/

Hello Doug,

On Thu, Oct 14, 2021 at 03:45:07PM -0000, Doug Swarin wrote:

> I believe strong and valid arguments can be made about the use of None
> being a fundamental flaw in some types of coding

Can you elaborate on that? Obviously it is not always appropriate to use
None, but I've never seen it called a *fundamental* flaw.

I know that the null pointer has been called a billion-dollar mistake,
but Python's None is not a null pointer.


--
Steve
_______________________________________________
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-leave@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/IGA7GYE2M6KQVOGIP3X2EESOXYUOMXMC/
Code of Conduct: http://python.org/psf/codeofconduct/

Steven D'Aprano wrote:
> Hello Doug,
> On Thu, Oct 14, 2021 at 03:45:07PM -0000, Doug Swarin wrote:
> > I believe strong and valid arguments can be made about the use of None
> > being a fundamental flaw in some types of coding
> > Can you elaborate on that? Obviously it is not always appropriate to use
> None, but I've never seen it called a *fundamental* flaw.
> I know that the null pointer has been called a billion-dollar mistake,
> but Python's None is not a null pointer.

I apologize that I may have spoken too strongly here. When I emailed Mr. Dower, he mentioned that he now believes the implementation of these operators would lead people to a style of coding which would lead to the proliferation of None as an exception-less error result and also throughout data structures. My understanding is that his current preference is to focus on functional composition and styles of programming that disallow the use of None.

I certainly don't mean to speak for him and I hope he will weigh in with a more detailed explanation of his thoughts and objections, but I personally disagree as a matter of pure practicality. It's just plain useful to be able to easily take non-values and safely deal with them without having to constantly check for None or to catch and inspect exceptions to see if it's a case that can be ignored.

I did indeed think about connecting None to the 'billion dollar mistake' but decided against it since as you say None is not a null pointer, and I should have chosen my words a little more carefully when revising my initial post (likely by removing the word 'fundamental').

Doug
_______________________________________________
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-leave@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/QDUJ6SIZWUMJ6YJDJRYZ4JA2GKSLJJ7I/
Code of Conduct: http://python.org/psf/codeofconduct/

On Fri, 15 Oct 2021 12:36:15 +1100
Steven D'Aprano <steve@pearwood.info> wrote:
> Hello Doug,
>
> On Thu, Oct 14, 2021 at 03:45:07PM -0000, Doug Swarin wrote:
>
> > I believe strong and valid arguments can be made about the use of None
> > being a fundamental flaw in some types of coding
>
> Can you elaborate on that? Obviously it is not always appropriate to use
> None, but I've never seen it called a *fundamental* flaw.
>
> I know that the null pointer has been called a billion-dollar mistake,
> but Python's None is not a null pointer.

(except in Cython, but that's Cython's fault here)

Regards

Antoine.


_______________________________________________
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-leave@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/GB2GZI3XHE4RJ4RSNAZB6QAOAU5DUK6J/
Code of Conduct: http://python.org/psf/codeofconduct/

Thanks for allowing me to speak for myself, as I said I would when
contacted off list :)

But as it happens, you've summarised my position very accurately:

> he now believes the implementation of these operators would lead people to a style of coding which would lead to the proliferation of None as an exception-less error result and also throughout data structures. My understanding is that his current preference is to focus on functional composition and styles of programming that disallow the use of None.

As additional context, C# and the .NET Framework have just gone through
the exercise of making (and propagating) non-nullable reference types
(and their "null" is far more like our None than C's NULL). Our type
checkers are also pushing in this direction by requiring Optional[]. The
argument in all cases is that it allows for simpler code that can safely
ignore non-values because they cannot be passed.

Adding ??, ?. and ?[., particularly in their short-circuiting evaluation
form, encourages more complex code by adding value-based branching
within an expression. And it encourages it on the "outside" of the API,
not within it. Which means API designers can more easily justify
returning None because their caller can use None-aware operators to
basically ignore it. (I would argue that the API designer should work
harder to create an API that doesn't ever have to return None.)

To be clear, I'm thinking very much in terms of "impact on what people
will consider to be Pythonic API design over the next 10 years", that
is, what people think they *should* do with this, rather than simply
what they *could*. So it's all very hypothetical and I have no data for
it, much like when it was decided that Optional[] would be mandatory on
types where None is permitted.

And with that, I'm bowing out of the fresh discussion (unless the SC
wants to discuss it directly with me). I'll continue advocating for
tools/features that help people create better APIs, but I'm not going to
spend a lot of time arguing against those that I believe will not.

Cheers,
Steve

On 10/15/2021 3:08 AM, Doug Swarin wrote:
> Steven D'Aprano wrote:
>> Hello Doug,
>> On Thu, Oct 14, 2021 at 03:45:07PM -0000, Doug Swarin wrote:
>>> I believe strong and valid arguments can be made about the use of None
>>> being a fundamental flaw in some types of coding
>>> Can you elaborate on that? Obviously it is not always appropriate to use
>> None, but I've never seen it called a *fundamental* flaw.
>> I know that the null pointer has been called a billion-dollar mistake,
>> but Python's None is not a null pointer.
>
> I apologize that I may have spoken too strongly here. When I emailed Mr. Dower, he mentioned that he now believes the implementation of these operators would lead people to a style of coding which would lead to the proliferation of None as an exception-less error result and also throughout data structures. My understanding is that his current preference is to focus on functional composition and styles of programming that disallow the use of None.
>
> I certainly don't mean to speak for him and I hope he will weigh in with a more detailed explanation of his thoughts and objections, but I personally disagree as a matter of pure practicality. It's just plain useful to be able to easily take non-values and safely deal with them without having to constantly check for None or to catch and inspect exceptions to see if it's a case that can be ignored.
>
> I did indeed think about connecting None to the 'billion dollar mistake' but decided against it since as you say None is not a null pointer, and I should have chosen my words a little more carefully when revising my initial post (likely by removing the word 'fundamental').
>
> Doug
_______________________________________________
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-leave@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/UIASDCES7GMQAMBNZGQZ65B2HSCPOEMD/
Code of Conduct: http://python.org/psf/codeofconduct/

NoneType is just another type, and in type checking scenarios should be
expressed with `Optional[type]` or more preferably in the future `type
| None`; `None` is not a non-value. Assuming what I just wrote is true,
I don't get what the basis of this thread is; what am I missing?

On Mon, 2021-10-18 at 14:13 +0100, Steve Dower wrote:
> Thanks for allowing me to speak for myself, as I said I would when
> contacted off list :)
>
> But as it happens, you've summarised my position very accurately:
>
> > he now believes the implementation of these operators would lead
> > people to a style of coding which would lead to the proliferation
> > of None as an exception-less error result and also throughout data
> > structures. My understanding is that his current preference is to
> > focus on functional composition and styles of programming that
> > disallow the use of None.
>
> As additional context, C# and the .NET Framework have just gone
> through
> the exercise of making (and propagating) non-nullable reference types
> (and their "null" is far more like our None than C's NULL). Our type
> checkers are also pushing in this direction by requiring Optional[].
> The
> argument in all cases is that it allows for simpler code that can
> safely
> ignore non-values because they cannot be passed.
>
> Adding ??, ?. and ?[., particularly in their short-circuiting
> evaluation
> form, encourages more complex code by adding value-based branching
> within an expression. And it encourages it on the "outside" of the
> API,
> not within it. Which means API designers can more easily justify
> returning None because their caller can use None-aware operators to
> basically ignore it. (I would argue that the API designer should work
> harder to create an API that doesn't ever have to return None.)
>
> To be clear, I'm thinking very much in terms of "impact on what
> people
> will consider to be Pythonic API design over the next 10 years", that
> is, what people think they *should* do with this, rather than simply
> what they *could*. So it's all very hypothetical and I have no data
> for
> it, much like when it was decided that Optional[] would be mandatory
> on
> types where None is permitted.
>
> And with that, I'm bowing out of the fresh discussion (unless the SC
> wants to discuss it directly with me). I'll continue advocating for
> tools/features that help people create better APIs, but I'm not going
> to
> spend a lot of time arguing against those that I believe will not.
>
> Cheers,
> Steve
>
> On 10/15/2021 3:08 AM, Doug Swarin wrote:
> > Steven D'Aprano wrote:
> > > Hello Doug,
> > > On Thu, Oct 14, 2021 at 03:45:07PM -0000, Doug Swarin wrote:
> > > > I believe strong and valid arguments can be made about the use
> > > > of None
> > > > being a fundamental flaw in some types of coding
> > > > Can you elaborate on that? Obviously it is not always
> > > > appropriate to use
> > > None, but I've never seen it called a *fundamental* flaw.
> > > I know that the null pointer has been called a billion-dollar
> > > mistake,
> > > but Python's None is not a null pointer.
> >
> > I apologize that I may have spoken too strongly here. When I
> > emailed Mr. Dower, he mentioned that he now believes the
> > implementation of these operators would lead people to a style of
> > coding which would lead to the proliferation of None as an
> > exception-less error result and also throughout data structures. My
> > understanding is that his current preference is to focus on
> > functional composition and styles of programming that disallow the
> > use of None.
> >
> > I certainly don't mean to speak for him and I hope he will weigh in
> > with a more detailed explanation of his thoughts and objections,
> > but I personally disagree as a matter of pure practicality. It's
> > just plain useful to be able to easily take non-values and safely
> > deal with them without having to constantly check for None or to
> > catch and inspect exceptions to see if it's a case that can be
> > ignored.
> >
> > I did indeed think about connecting None to the 'billion dollar
> > mistake' but decided against it since as you say None is not a null
> > pointer, and I should have chosen my words a little more carefully
> > when revising my initial post (likely by removing the word
> > 'fundamental').
> >
> > Doug
> _______________________________________________
> Python-Dev mailing list -- python-dev@python.org
> To unsubscribe send an email to python-dev-leave@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/UIASDCES7GMQAMBNZGQZ65B2HSCPOEMD/
> Code of Conduct: http://python.org/psf/codeofconduct/

On Mon, Oct 18, 2021 at 9:35 AM Paul Bryan <pbryan@anode.ca> wrote:

> NoneType is just another type, and in type checking scenarios should be
> expressed with `Optional[type]` or more preferably in the future `type |
> None`; `None` is not a non-value. Assuming what I just wrote is true, I
> don't get what the basis of this thread is; what am I missing?
>

To me the thread isn't about type checking. It is about APIs that are built
into the language that special-case None, in particular dict.get(). In
certain cases, encountered commonly in certain styles of coding (data
science? web programming?), users encounter data that is structured as
dicts nested multiple levels. This is often out of the user's control, as
the dict is returned by reading a JSON value whose structure is controlled
by some other framework (often not specific to Python).

For example, if we have a config structure like this:

config = {
"timeout": 0.1,
"handler: {
"timeout-override": 0.4,
"method-name": "plot",
"parameters": {
"x": 10,
"y": "auto",
}
}
}

where the convention is that keys at any level may be omitted altogether
and config itself may be NOne, then to safely access the value of
config["handler"]["parameters"]["y"] we would have to write

y = None # Default
if config is not None:
handler = config.get("handler")
if handler is not None:
parameters = handler.get("parameters")
if parameters is not None:
y = parameters.get("y")

This kind of pattern (and all the various other ways of writing it, e.g.
using the walrus or passing {} as the second argument to dict.get()) can be
*very* common if that's the kind of data you're given and that's the kind
of app you have to write, and you can't control the format of the data.

Using ?. this can be written as

y = config?.get("handler")?.get("parameters")?.get("y")

More examples are in PEP 505 itself, see
https://www.python.org/dev/peps/pep-0505/#examples

--
--Guido van Rossum (python.org/~guido)
*Pronouns: he/him **(why is my pronoun here?)*
<http://feministing.com/2015/02/03/how-using-they-as-a-singular-pronoun-can-change-the-world/>

On Mon, 18 Oct 2021 at 19:29, Guido van Rossum <guido@python.org> wrote:

> where the convention is that keys at any level may be omitted altogether and config itself may be NOne, then to safely access the value of config["handler"]["parameters"]["y"] we would have to write
>
> y = None # Default
> if config is not None:
> handler = config.get("handler")
> if handler is not None:
> parameters = handler.get("parameters")
> if parameters is not None:
> y = parameters.get("y")
>
> This kind of pattern (and all the various other ways of writing it, e.g. using the walrus or passing {} as the second argument to dict.get()) can be *very* common if that's the kind of data you're given and that's the kind of app you have to write, and you can't control the format of the data.
>
> Using ?. this can be written as
>
> y = config?.get("handler")?.get("parameters")?.get("y")
>
> More examples are in PEP 505 itself, see https://www.python.org/dev/peps/pep-0505/#examples

For this particular usage, I'd much rather have a functional API, like

y = get_config(config, "handler", "parameters", "y")

I understand that writing many helpers like that nested_get is a
chore, and having language support for the operation avoids that chore
- but I'm with Steve in not wanting to see the ?.get() pattern become
"idiomatic Python" as it encourages people *not* to design APIs like
nested_get that allow the user to not even be aware of all that
behind-the-scenes complexity. Sure, you could argue that the ?.
operator makes it easier to write something like get_config, but it's
not *that* hard:

def get_config(config, *keys):
value = config
for key in keys:
if value is None:
break
value = value.get(key)
return value

And the problem with the ?.get style is that it doesn't hide anything
- what if you want/need to change your config data structure (because
the JSON you're reading changes its layout, say)? Without
encapsulation, you can't. And if it's *that* common, adding a stdlib
function or a new dict method is also an option, which doesn't need a
language feature and demonstrates good (IMO) API design for people to
copy.

Anyway, much like Steve, I don't expect to spend a lot of time
fighting this proposal. But I will be sad if it gets accepted, and
even more so if ?. becomes idiomatic in user code.

Paul
_______________________________________________
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-leave@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/55SOK3J6YRIOEBX47INLLTAVUZRMD57Z/
Code of Conduct: http://python.org/psf/codeofconduct/

On Mon, Oct 18, 2021 at 6:49 PM Paul Moore <p.f.moore@gmail.com> wrote:

> On Mon, 18 Oct 2021 at 19:29, Guido van Rossum <guido@python.org> wrote:
> > y = None # Default
> > if config is not None:
> > handler = config.get("handler")
> > if handler is not None:
> > parameters = handler.get("parameters")
> > if parameters is not None:
> > y = parameters.get("y")
>
> For this particular usage, I'd much rather have a functional API, like
> y = get_config(config, "handler", "parameters", "y")
>

I agree with Paul here... and am pretty sure I did the last time this went
around. Whenever the issue comes up, it's about JSON. Or *maybe* about
something very similar that goes by another name or format details.

And there already exists a pretty good, pretty standard, approach called
JSONPath that deals with exactly this kind of thing. This, in turn, is
largely the same as XPath which serves the same role for XML documents.

I don't think it necessarily needs to be in the standard library, but the
mini-language for extracting data from trees with frequently missing
branches can very well simply be a mini-language. It'll wind up a lot like
XPath/JSONPath, but something a little bit different could be good too.

--
Keeping medicines from the bloodstreams of the sick; food
from the bellies of the hungry; books from the hands of the
uneducated; technology from the underdeveloped; and putting
advocates of freedom in prisons. Intellectual property is
to the 21st century what the slave trade was to the 16th.

Big +1 from me. I've been looking forward to having None-aware operators in
Python as I find them a very neat language addition.

For me personally the main advantage of having maybe-dot (?.) operator is
the ability to express certain logic in a much clearer way, for example:

> class User(DBModel):
> phone: str | None
>
> class Publisher(DBModel):
> owner: ForeignKey[User] | None
>
> class Book(DBModel)
> publisher: ForeignKey[Publisher] | None


Imagine wanting to get the phone number of the person that published a
certain book from the database.
In this situation, with maybe-dot operator I can write:

> phone_number = book.publisher?.owner?.phone

Getting None value could mean that the book has not been published yet (no
publisher relation), owner does not exist or does not have a phone number
associated with it.
Either way it doesn't matter because the only thing that we wanted to
retrieve is the phone number and not the whole context of why it has a
certain value and not the other.

Personally I find this syntax much more readable than other, "more
explicit" expressions like:
> phone_number = book.publisher.owner.phone if (book.publisher is not None
and book.publisher.owner is not None) else None

Best regards,

On Thu, Oct 14, 2021 at 7:37 PM Doug Swarin <dswarin@gmail.com> wrote:

> Hello,
>
> I've been following PEP 505 (https://www.python.org/dev/peps/pep-0505/)
> since it was first proposed for Python 3.8. It's been deferred for some
> time and I'm interested in seeing it in Python 3.11, but I know there were
> also a number of objections which resulted in it being deferred (including
> by one of the original authors, Mr. Dower). I did email both Mr. Dower and
> Mr. Haase and they graciously gave me their permission to bring it up on
> this list for discussion and hopefully final pronouncement one way or the
> other.
>
> I personally believe that the PEP will result in a significant reduction
> in boilerplate code, and it is substantially similar to the same operators
> now found in a number of other languages, especially C# and JavaScript (
> https://wikipedia.org/wiki/Null_coalescing_operator and
> https://wikipedia.org/wiki/Safe_navigation_operator).
>
> I believe strong and valid arguments can be made about the use of None
> being a fundamental flaw in some types of coding (and that adding
> additional support for it to the language will increase the use of None in
> this way), but I also believe there are many use cases in programming where
> it is by far the simplest way to express various semantics, and the fact
> exists that None is already used extensively in large quantities of code,
> and further that there is already a great deal of code written to
> constantly test against None and break out of a statement without throwing
> an error.
>
> I also understand the argument that especially the maybe-dot (?.) and
> maybe-subscript (?[) operators can decrease readability of code and also
> believe these are valid arguments against it. While I believe the existence
> and use of these operators in other languages definitely helps the case
> that these can be used and understood successfully, I think it is entirely
> valid to either consider other syntax (though I prefer the chosen syntax of
> PEP 505), or even to reduce PEP 505 to having only the coalesce operator
> (??) and the maybe-assign operator (??=).
>
> Separately, I have implemented a pure-Python solution for PEP505 (which is
> definitely rather beta) which might help test the waters for a final
> implementation in CPython (though the CPython implementation would of
> course be much more efficient). It can be found at
> https://pypi.org/project/pep505/
>
> Thanks,
> Doug
> _______________________________________________
> Python-Dev mailing list -- python-dev@python.org
> To unsubscribe send an email to python-dev-leave@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/XZZIV42XGG3EIHRBBCCTTCFPWWSOT7MX/
> Code of Conduct: http://python.org/psf/codeofconduct/
>

Data point: I find all the examples in PEP 505 less readable using the
proposed new operators.
Trying to explain why: The syntax feels *too* compact (Perl-like?) -
when reading it, every time you see a None-aware operator (*if* you
notice it), you have to jerk to a halt and say, "Whoa!  What's going on
here?".
I have some sympathy with this use case of exploring a nested-dict (JSON
derived?) structure, but this can be written as

try:
    config.get("handler").get("parameters").get("y")
except Attribute Error:
    # Handle missing value.

or something similar (I haven't tested it).  Even using the new
operators, in a realistic case you would probably have to test if the
result is None and take different action accordingly.
Best wishes
Rob Cliffe

On 18/10/2021 19:26, Guido van Rossum wrote:
> On Mon, Oct 18, 2021 at 9:35 AM Paul Bryan <pbryan@anode.ca
> <mailto:pbryan@anode.ca>> wrote:
>
> NoneType is just another type, and in type checking scenarios
> should be expressed with `Optional[type]` or more preferably in
> the future `type | None`; `None` is not a non-value. Assuming what
> I just wrote is true, I don't get what the basis of this thread
> is; what am I missing?
>
>
> To me the thread isn't about type checking. It is about APIs that are
> built into the language that special-case None, in particular
> dict.get(). In certain cases, encountered commonly in certain styles
> of coding (data science? web programming?), users encounter data that
> is structured as dicts nested multiple levels. This is often out of
> the user's control, as the dict is returned by reading a JSON value
> whose structure is controlled by some other framework (often not
> specific to Python).
>
> For example, if we have a config structure like this:
>
> config = {
>   "timeout": 0.1,
>   "handler: {
>     "timeout-override": 0.4,
>     "method-name": "plot",
>     "parameters": {
>       "x": 10,
>       "y": "auto",
>     }
>   }
> }
>
> where the convention is that keys at any level may be omitted
> altogether and config itself may be NOne, then to safely access the
> value of config["handler"]["parameters"]["y"] we would have to write
>
> y = None  # Default
> if config is not None:
>   handler = config.get("handler")
>   if handler is not None:
>     parameters = handler.get("parameters")
>     if parameters is not None:
>       y = parameters.get("y")
>
> This kind of pattern (and all the various other ways of writing it,
> e.g. using the walrus or passing {} as the second argument to
> dict.get()) can be *very* common if that's the kind of data you're
> given and that's the kind of app you have to write, and you can't
> control the format of the data.
>
> Using ?. this can be written as
>
> y = config?.get("handler")?.get("parameters")?.get("y")
>
> More examples are in PEP 505 itself, see
> https://www.python.org/dev/peps/pep-0505/#examples
> <https://www.python.org/dev/peps/pep-0505/#examples>
>
> --
> --Guido van Rossum (python.org/~guido <http://python.org/~guido>)
> /Pronouns: he/him //(why is my pronoun here?)/
> <http://feministing.com/2015/02/03/how-using-they-as-a-singular-pronoun-can-change-the-world/>
>
> _______________________________________________
> Python-Dev mailing list -- python-dev@python.org
> To unsubscribe send an email to python-dev-leave@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/GKOYEMS7RFHTRPDJ23RAHBBNTFDXKGFJ/
> Code of Conduct: http://python.org/psf/codeofconduct/

Okay, I'll let myself get sucked into responding ONE TIME, but only
because you gave me such a nice API to work with :)

On 10/18/2021 9:11 PM, Piotr Waszkiewicz wrote:
> > class User(DBModel):
> >    phone: str | None
> >
> > class Publisher(DBModel):
> >   owner: ForeignKey[User] | None
> >
> > class Book(DBModel)
> >     publisher: ForeignKey[Publisher] | None
>
>
> Imagine wanting to get the phone number of the person that published a
> certain book from the database.
> In this situation, with maybe-dot operator I can write:
>
> > phone_number = book.publisher?.owner?.phone

Consider today, you wrote this as "book.publisher.owner.phone". You
would potentially get AttributeError, from any one of the elements - no
way to tell which, and no way to react.

Generally, AttributeError indicates that you've provided a value to an
API which doesn't fit its pattern. In other words, it's an error about
the *type* rather than the value.

But in this case, the (semantic, not implementation) *type* is known and
correct - it's a publisher! It just happens that the API designed it
such that when the *value* is unknown, the *type* no longer matches.

This is PRECISELY the kind of (IMHO, bad) API design that None-aware
operators will encourage.


Consider an alternative:

class ForeignKey:
...
def __bool__(self):
return not self.is_dbnull

def value(self):
if self.is_dbnull:
return self.Type.empty() # that is, DBModel.empty()
return self._value


class DBModel:
@classmethod
def empty(cls):
return cls(__secret_is_empty_flag=True)

def __bool__(self):
return not self._is_empty

def __getattr__(self, key):
if not self:
t = self._get_model_type(key)
return t.empty() if isinstance(t, DBModel) else None
...

class User(DBModel):
phone: str | None

class Publisher(DBModel):
owner: ForeignKey[User]

class Book(DBModel)
publisher: ForeignKey[Publisher]


Okay, so as the API implementer, I've had to do a tonne more work.
That's fine - *that's my job*. The user hasn't had to stick "| None"
everywhere (and when we eventually get around to allowing named
arguments in indexing then they could use "ForeignKey[User,
non_nullable=True]", but I guess for now that would be some subclass of
ForeignKey).

But now here's the example again:

> book.publisher.owner.phone

If there is no publisher, it'll return None. If there is no owner, it'll
return None. If the owner has no phone number, it'll return None.

BUT, if you misspell "owner", it will raise AttributeError, because you
referenced something that is not part of the *type*. And that error will
be raised EVERY time, not just in the cases where 'publisher' is
non-null. It takes away the random value-based errors we've come to love
from poorly coded web sites and makes them reliably based on the value's
type (and doesn't even require a type checker ;) ).

Additionally, if you want to explicitly check whether a FK is null, you
can do everything with regular checks:

if book.publisher.owner:
# we know the owner!
else:
# we don't know

# Get all owner names - including where the name is None - but only if
# Mrs. None actually published a book (and not just because we don't
# know a book's publisher or a publisher's owner)
owners = {book.id: book.publisher.owner.name
for book in all_books
if book.publisher.owner}

# Update a null FK with a lazy lookup
book.publisher = book.publisher or publishers.get(...)


You can't do anything useful with a native None here besides test for
it, and there are better ways to do that test. So None is not a useful
value compared to a rich DBModel subclass that *knows* it is empty.

---

So to summarise my core concern - allowing an API designer to "just use
None" is a cop out, and it lets people write lazy/bad APIs rather than
coming up with good ones.

Cheers,
Steve
_______________________________________________
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-leave@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/BRTRKGY6RLTHZJQ2US4LO7DYLSGXQ5GM/
Code of Conduct: http://python.org/psf/codeofconduct/

I should have added that I also don't feel I want to go at bat to fight for
this PEP. I do observe that it looks like the folks used to building large
systems (in Python or other languages) don't seem to like it, while it
seems to appeal to folks writing simpler code (the abundant majority of
Python users, but not of Python core devs). I worry that the experienced
folks may perhaps be a little too eager to protect newbies from shooting
themselves in the foot.

--
--Guido van Rossum (python.org/~guido)
*Pronouns: he/him **(why is my pronoun here?)*
<http://feministing.com/2015/02/03/how-using-they-as-a-singular-pronoun-can-change-the-world/>

On Tue, 19 Oct 2021 at 00:55, Guido van Rossum <guido@python.org> wrote:
>
> I should have added that I also don't feel I want to go at bat to fight for this PEP. I do observe that it looks like the folks used to building large systems (in Python or other languages) don't seem to like it, while it seems to appeal to folks writing simpler code (the abundant majority of Python users, but not of Python core devs). I worry that the experienced folks may perhaps be a little too eager to protect newbies from shooting themselves in the foot.

Possibly. But in *my* case, I'm not arguing from the position of a
large system builder, but from that of a script writer (albeit an
experienced one) and code maintainer (usually of my own code).

I find y = config?.get("handler")?.get("parameters")?.get("y")
unreadable and confusing, and I'd probably advise strongly against it
if someone ever showed me code containing it. I see y =
get_config(config, "handler", "parameters", "y") as *far* more
readable and expressing the intent more directly.

Yes, I find Steve's arguments persuasive, but they are not the ones
I'd be concerned with when advising a newcomer. Rather I'd be saying
"do you see how using a named function expresses your intent better?"
and "do you see how writing a small function hides the messiness of
checking for None so that your main code is cleaner?"

*Shrug* I guess I just don't understand how people can look at a
string of ?.get() and see it as readable and obvious :-(

Paul
_______________________________________________
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-leave@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/QOWSJXN3WE7WLUYB22HZNOZJ6GGGRWVF/
Code of Conduct: http://python.org/psf/codeofconduct/

Thank you very much for this exhaustive explanation and example. I really
like it and agree with you that the implementation provided by your example
is much more well designed.

The problem I have with it is that I feel like it assumes that I have a way
to introduce such changes when writing the API, whereas I was talking more
about using existing solutions.
The provided example was based on common situations encountered when
writing the code in Django. It may be that I'm using this tool not to its
full potential, but it seems like many of your points were about bad API
design, not the actual maybe-dot operator.

Such operator would make it much easier to work with those frameworks that
do not allow for more readable/well thought-out solutions. I'm thinking
about it as a syntactic sugar that can speed things up (and even make it
more readable) in a situation where there is no time and/or budget to come
up with a better architecture (like e.g. the one you have provided). The
reality is that usually from the business perspective nobody wants a well
designed system, only the functioning one.

It may be that I misunderstood your response and didn't provide a valid
answer - please let me know in that case.

Best regards

On Tue, Oct 19, 2021 at 1:29 AM Steve Dower <steve.dower@python.org> wrote:

> Okay, I'll let myself get sucked into responding ONE TIME, but only
> because you gave me such a nice API to work with :)
>
> On 10/18/2021 9:11 PM, Piotr Waszkiewicz wrote:
> > > class User(DBModel):
> > > phone: str | None
> > >
> > > class Publisher(DBModel):
> > > owner: ForeignKey[User] | None
> > >
> > > class Book(DBModel)
> > > publisher: ForeignKey[Publisher] | None
> >
> >
> > Imagine wanting to get the phone number of the person that published a
> > certain book from the database.
> > In this situation, with maybe-dot operator I can write:
> >
> > > phone_number = book.publisher?.owner?.phone
>
> Consider today, you wrote this as "book.publisher.owner.phone". You
> would potentially get AttributeError, from any one of the elements - no
> way to tell which, and no way to react.
>
> Generally, AttributeError indicates that you've provided a value to an
> API which doesn't fit its pattern. In other words, it's an error about
> the *type* rather than the value.
>
> But in this case, the (semantic, not implementation) *type* is known and
> correct - it's a publisher! It just happens that the API designed it
> such that when the *value* is unknown, the *type* no longer matches.
>
> This is PRECISELY the kind of (IMHO, bad) API design that None-aware
> operators will encourage.
>
>
> Consider an alternative:
>
> class ForeignKey:
> ...
> def __bool__(self):
> return not self.is_dbnull
>
> def value(self):
> if self.is_dbnull:
> return self.Type.empty() # that is, DBModel.empty()
> return self._value
>
>
> class DBModel:
> @classmethod
> def empty(cls):
> return cls(__secret_is_empty_flag=True)
>
> def __bool__(self):
> return not self._is_empty
>
> def __getattr__(self, key):
> if not self:
> t = self._get_model_type(key)
> return t.empty() if isinstance(t, DBModel) else None
> ...
>
> class User(DBModel):
> phone: str | None
>
> class Publisher(DBModel):
> owner: ForeignKey[User]
>
> class Book(DBModel)
> publisher: ForeignKey[Publisher]
>
>
> Okay, so as the API implementer, I've had to do a tonne more work.
> That's fine - *that's my job*. The user hasn't had to stick "| None"
> everywhere (and when we eventually get around to allowing named
> arguments in indexing then they could use "ForeignKey[User,
> non_nullable=True]", but I guess for now that would be some subclass of
> ForeignKey).
>
> But now here's the example again:
>
> > book.publisher.owner.phone
>
> If there is no publisher, it'll return None. If there is no owner, it'll
> return None. If the owner has no phone number, it'll return None.
>
> BUT, if you misspell "owner", it will raise AttributeError, because you
> referenced something that is not part of the *type*. And that error will
> be raised EVERY time, not just in the cases where 'publisher' is
> non-null. It takes away the random value-based errors we've come to love
> from poorly coded web sites and makes them reliably based on the value's
> type (and doesn't even require a type checker ;) ).
>
> Additionally, if you want to explicitly check whether a FK is null, you
> can do everything with regular checks:
>
> if book.publisher.owner:
> # we know the owner!
> else:
> # we don't know
>
> # Get all owner names - including where the name is None - but only if
> # Mrs. None actually published a book (and not just because we don't
> # know a book's publisher or a publisher's owner)
> owners = {book.id: book.publisher.owner.name
> for book in all_books
> if book.publisher.owner}
>
> # Update a null FK with a lazy lookup
> book.publisher = book.publisher or publishers.get(...)
>
>
> You can't do anything useful with a native None here besides test for
> it, and there are better ways to do that test. So None is not a useful
> value compared to a rich DBModel subclass that *knows* it is empty.
>
> ---
>
> So to summarise my core concern - allowing an API designer to "just use
> None" is a cop out, and it lets people write lazy/bad APIs rather than
> coming up with good ones.
>
> Cheers,
> Steve
> _______________________________________________
> Python-Dev mailing list -- python-dev@python.org
> To unsubscribe send an email to python-dev-leave@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/BRTRKGY6RLTHZJQ2US4LO7DYLSGXQ5GM/
> Code of Conduct: http://python.org/psf/codeofconduct/
>

Le 18/10/2021 à 20:26, Guido van Rossum a écrit :
>
> y = None  # Default
> if config is not None:
>   handler = config.get("handler")
>   if handler is not None:
>     parameters = handler.get("parameters")
>     if parameters is not None:
>       y = parameters.get("y")
>
> […]
> Using ?. this can be written as
>
> y = config?.get("handler")?.get("parameters")?.get("y")

Sure, but the EAFP version is not that bad:

try:
y = config["handler"]["parameters"]["y"]
except KeyError:
y = None

which could be further simplified with an exception-catching expression
(caveat: keyword usage is pure improvisation, it sounds good, but is
probably broken :-) :

y = config["handler"]["parameters"]["y"] with KeyError as None

The PEP authors would probably reject this as "hiding errors in code",
which is true, but none-aware operators also hide errors…

Cheers,
Baptiste
_______________________________________________
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-leave@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/JWZ2ZG7AIXXWDGNPUZDVLORDFMMEP3XV/
Code of Conduct: http://python.org/psf/codeofconduct/

On Wed, Oct 20, 2021 at 3:25 AM Baptiste Carvello
<devel2021@baptiste-carvello.net> wrote:
>
> Le 18/10/2021 à 20:26, Guido van Rossum a écrit :
> >
> > y = None # Default
> > if config is not None:
> > handler = config.get("handler")
> > if handler is not None:
> > parameters = handler.get("parameters")
> > if parameters is not None:
> > y = parameters.get("y")
> >
> > […]
> > Using ?. this can be written as
> >
> > y = config?.get("handler")?.get("parameters")?.get("y")
>
> Sure, but the EAFP version is not that bad:
>
> try:
> y = config["handler"]["parameters"]["y"]
> except KeyError:
> y = None
>
> which could be further simplified with an exception-catching expression
> (caveat: keyword usage is pure improvisation, it sounds good, but is
> probably broken :-) :
>
> y = config["handler"]["parameters"]["y"] with KeyError as None
>
> The PEP authors would probably reject this as "hiding errors in code",
> which is true, but none-aware operators also hide errors…

PEP 463 would like to say hi :)

ChrisA
_______________________________________________
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-leave@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/M5XHRRAE3CIQACYHU4Q3TBMFXIUYYI3N/
Code of Conduct: http://python.org/psf/codeofconduct/

Steve Dower wrote:
> Okay, I'll let myself get sucked into responding ONE TIME, but only
> because you gave me such a nice API to work with :)

This actually pushed me hard towards adding the null-aware operators. I agree that the named-function approach Paul suggests is better. I admit that there are times when a comprehensive model is good, and that if the DB schema is automatically generated, it should look something like this.

But this is long enough that I would be unhappy if it were what I had to read to understand the database in the first place. (Yes, I know Java beans are pretty widely tolerated, but ... that doesn't make longer code desirable.)
_______________________________________________
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-leave@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/OFZZ4PYT4EWTXHZ2PGRO3FBFRPCV4NZC/
Code of Conduct: http://python.org/psf/codeofconduct/

I will also say that I don't believe the safe-navigation operators necessarily compromise type safety. PEP 505 explicitly rejects having them catch `AttributeError` or `KeyError` (and I agree with this rejection). It's not the default behavior of objects to return None when an unknown attribute is read, so attempting to access `book?.publisher?.onwer?.name` will still fail with `AttributeError`. Type checkers would also continue being able to check such navigation.

Doug
_______________________________________________
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-leave@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/V4PK74K7W74EJ5XMXPEB6FLAZCDJ6SCN/
Code of Conduct: http://python.org/psf/codeofconduct/

On Tue, Oct 19, 2021 at 9:39 AM Chris Angelico <rosuav@gmail.com> wrote:

> On Wed, Oct 20, 2021 at 3:25 AM Baptiste Carvello
> <devel2021@baptiste-carvello.net> wrote:
> >
> > Le 18/10/2021 à 20:26, Guido van Rossum a écrit :
> > >
> > > y = None # Default
> > > if config is not None:
> > > handler = config.get("handler")
> > > if handler is not None:
> > > parameters = handler.get("parameters")
> > > if parameters is not None:
> > > y = parameters.get("y")
> > >
> > > […]
> > > Using ?. this can be written as
> > >
> > > y = config?.get("handler")?.get("parameters")?.get("y")
> >
> > Sure, but the EAFP version is not that bad:
> >
> > try:
> > y = config["handler"]["parameters"]["y"]
> > except KeyError:
> > y = None
> >
> > which could be further simplified with an exception-catching expression
> > (caveat: keyword usage is pure improvisation, it sounds good, but is
> > probably broken :-) :
> >
> > y = config["handler"]["parameters"]["y"] with KeyError as None
> >
> > The PEP authors would probably reject this as "hiding errors in code",
> > which is true, but none-aware operators also hide errors…
>
> PEP 463 would like to say hi :)
>

In case it saves anyone a couple clicks:
https://www.python.org/dev/peps/pep-0463/

I also prefer more syntactic help with exceptions, rather than more syntax
emphasizing None's uniqueness.

None and its ilk often conflate too many qualities. For example, is it
missing because it doesn't exist, it never existed, or because we never
received a value, despite knowing it must exist? The languages SAS and R
support at least 27 varieties of NA, allowing un-tagged, and tagged with
the letters A-Z to help someone create distinctions between different kinds
of nothingness. IEEE-754 allows about 16 million possible NaNs, which I
believe was intended to allow floating point instructions to pass error
messages along.

If the motivation for this operator is chained lookups, how about adding a
feature to the operator module, first? It seems natural to add a
keyword-only argument to `attrgetter`, and it's a lighter touch than
implementing a new operator. If use becomes widespread, that gives more
weight to PEP 505.

def attrgetter(*attrs, none_aware=False)

https://docs.python.org/3/library/operator.html#operator.attrgetter

Apologies if attrgetter has already been discussed. I didn't see mention of
it in PEP 505.

Baptiste Carvello wrote:
> y = config["handler"]["parameters"]["y"] with KeyError as None

I love the look of this! While it doesn't address everything that PEP505 does, that's IMO a good thing, because - as other people mentioned already - None does too many things already.

On another note, the whole discussion reminds me of wg21.link/p0798, which is about adding something quite similar to C++ (was accepted into C++23), and contains a decent overview of how other languages solve the same thing.

Even though the approach there is probably not applicable (as all python types are implicitly `Optional` in the sense of "can be None", i.e. that API would have to be added all the way down to `object`), it's still ironic that C++'s `and_then` looks more pythonic than what's proposed here.
_______________________________________________
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-leave@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/6JD5VGTVE2TVHUMU7OWIYT7QJEKAGRI7/
Code of Conduct: http://python.org/psf/codeofconduct/

This is very reminiscent of the (rejected) PEP 463, Exception-catching
expressions (which I still hope will be resurrected some day).  It would
allow you to write
    y = (config["handler"]["parameters"]["y"] except KeyError: None)
(possibly the parentheses might not be required) which IMO is even
better; `except` makes the intent clearer than `with`.
Best wishes
Rob Cliffe

On 20/10/2021 03:05, h.vetinari@gmx.com wrote:
> Baptiste Carvello wrote:
>> y = config["handler"]["parameters"]["y"] with KeyError as None
> I love the look of this! While it doesn't address everything that PEP505 does, that's IMO a good thing, because - as other people mentioned already - None does too many things already.
>
> On another note, the whole discussion reminds me of wg21.link/p0798, which is about adding something quite similar to C++ (was accepted into C++23), and contains a decent overview of how other languages solve the same thing.
>
> Even though the approach there is probably not applicable (as all python types are implicitly `Optional` in the sense of "can be None", i.e. that API would have to be added all the way down to `object`), it's still ironic that C++'s `and_then` looks more pythonic than what's proposed here.
> _______________________________________________
> Python-Dev mailing list -- python-dev@python.org
> To unsubscribe send an email to python-dev-leave@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/6JD5VGTVE2TVHUMU7OWIYT7QJEKAGRI7/
> Code of Conduct: http://python.org/psf/codeofconduct/

_______________________________________________
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-leave@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/FXOAXI72DN355PD3RKQOMAELA5XHOGKN/
Code of Conduct: http://python.org/psf/codeofconduct/

Hi,

On Wed, Oct 20, 2021 at 2:33 AM Michael Selik <mike@quantami.com> wrote:

> In case it saves anyone a couple clicks:
> https://www.python.org/dev/peps/pep-0463/
>
> I also prefer more syntactic help with exceptions, rather than more syntax
> emphasizing None's uniqueness.
>

Me too, but could you provide me an example where try-except approach is
more readable when trying to chain attribute lookups (like in the database
book-publisher-owner example I have provided before).


>
> None and its ilk often conflate too many qualities. For example, is it
> missing because it doesn't exist, it never existed, or because we never
> received a value, despite knowing it must exist?
>

I think that a code where those three qualities happen all at once is in
fact a bad code design. But the truth is that None has been and will be
used to denote each of those qualities when writing a code because of its
ease of use in a normal workflow, where time constraints are tight.


> The languages SAS and R support at least 27 varieties of NA, allowing
> un-tagged, and tagged with the letters A-Z to help someone create
> distinctions between different kinds of nothingness. IEEE-754 allows about
> 16 million possible NaNs, which I believe was intended to allow floating
> point instructions to pass error messages along.
>
> If the motivation for this operator is chained lookups, how about adding a
> feature to the operator module, first? It seems natural to add a
> keyword-only argument to `attrgetter`, and it's a lighter touch than
> implementing a new operator. If use becomes widespread, that gives more
> weight to PEP 505.
>
> def attrgetter(*attrs, none_aware=False)
>
> https://docs.python.org/3/library/operator.html#operator.attrgetter
>
> Apologies if attrgetter has already been discussed. I didn't see mention
> of it in PEP 505.
>

I remember using inhouse solution like this at a certain workplace - a
method accepting list of string arguments and an object, returning the
value being the result of chained attribute access. And it worked all right.
The problem I have with such approaches is that the name of the attrs are
passed as strings. This makes it less practical in day-to-day situations
when writing code. Automated class refactors, available in most of the IDEs
also seem to not be able to support such field renames, whereas attribute
lookup via `.` is properly detected. The same goes with context help
available in most IDEs - you'll get no useful information when writing a
string (IDE does not know if you are trying to write a name of the class'
field), whereas when using the dot this works. And it'll probably be
implemented for maybe-dot operator in no time looking at other languages'
support.


> _______________________________________________
> Python-Dev mailing list -- python-dev@python.org
> To unsubscribe send an email to python-dev-leave@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/R5NO5H5BCEIGEUCLPRE7WW5AEG5MRX3Q/
> Code of Conduct: http://python.org/psf/codeofconduct/
>